The blob-based scheme is really no different than what we have today.
In the past, we *have* talked about applying limitations (since we
don't do streamy stuff with props), but simply never coded any.
Cheers,
-g
On Fri, Jan 9, 2009 at 05:51, Branko Čibej <brane_at_xbc.nu> wrote:
> Looking at that diff, I'm a bit worried about having all the property
> values serialized in the same blob. Before this change, each value was
> in a separate row in the database ... Now, adding a large property will
> affect the performance of all property-related queries.
>
> Note that we've never suggested or imposed any limitations on prop value
> size.
>
> Greg Stein wrote:
>> On Thu, Jan 8, 2009 at 16:37, Blair Zajac <blair_at_orcaware.com> wrote:
>>
>>> Hyrum K. Wright wrote:
>>>
>>>> Author: hwright
>>>> Date: Thu Jan 8 13:25:09 2009
>>>> New Revision: 35086
>>>>
>>>> Log:
>>>> Followup to r35085: Remove another properties-related table in favor of BLOB
>>>> column in yet another table.
>>>>
>>> Is there a reason we're using BLOBs as all in our database? It seems useful to
>>> have all the data represented in SQL
>>>
>>> This is definitely de-normalizing the data :)
>>>
>>> I could imaging writing small Python scripts to query the SQL or do other stuff
>>> in there. If we have BLOBs, that means it's not as straight forward.
>>>
>>
>> If you can show that the performance of selecting N rows from a
>> properties table and constructing a prop hash is the same or faster
>> than deserializing a BLOB from the same row as the node... then, sure.
>> Maybe that makes sense.
>>
>> Also note that these tables are *private* to the WC. We do not have to
>> make any concessions for external scripts, which should be using WC
>> APIs anyways. As such, we are optimizing for overall performance. If
>> we can get clarity at a small perf cost, then sure... we'd do that.
>> But for the moment, I believe that a BLOB is going to be significantly
>> faster than N rows. I'm happy to see somebody demonstrate otherwise
>> tho...
>>
>> Cheers,
>> -g
>>
>
>
Received on 2009-01-09 16:58:41 CET