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
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
>>> 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
Received on 2009-01-09 14:51:35 CET