[svn.haxx.se] · SVN Dev · SVN Users · SVN Org · TSVN Dev · TSVN Users · Subclipse Dev · Subclipse Users · this month's index

Re: svn commit: r35086 - trunk/subversion/libsvn_wc

From: Blair Zajac <blair_at_orcaware.com>
Date: Fri, 09 Jan 2009 09:33:41 -0800

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...

Isn't this premature optimization? Do we know how much slower using a BLOB will
be than a separate table? Sure, it will be slower, but how much?

 From what I understand when designing schemas, you start off with a normalized
one than denormalize it as necessary for performance.


Received on 2009-01-09 22:32:42 CET

This is an archived mail posted to the Subversion Dev mailing list.