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
>
------------------------------------------------------
http://subversion.tigris.org/ds/viewMessage.do?dsForumId=462&dsMessageId=1013752
Received on 2009-01-09 14:51:35 CET