[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: Greg Stein <gstein_at_gmail.com>
Date: Fri, 9 Jan 2009 07:58:24 -0800

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

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

This site is subject to the Apache Privacy Policy and the Apache Public Forum Archive Policy.