Dne 10.12.2012 16:38, Andres Freund napsal:
> On 2012-12-08 17:07:38 +0100, Tomas Vondra wrote:
>> I've done some test and yes - once there are other objects the
>> optimization falls short. For example for tables with one index, it
>> looks like this:
>>
>> 1) unpatched
>>
>> one by one: 28.9 s
>> 100 batches: 23.9 s
>>
>> 2) patched
>>
>> one by one: 44.1 s
>> 100 batches: 4.7 s
>>
>> So the patched code is by about 50% slower, but this difference
>> quickly
>> disappears with the number of indexes / toast tables etc.
>>
>> I see this as an argument AGAINST such special-case optimization. My
>> reasoning is this:
>>
>> * This difference is significant only if you're dropping a table
>> with
>> low number of indexes / toast tables. In reality this is not going
>> to
>> be very frequent.
>>
>> * If you're dropping a single table, it really does not matter - the
>> difference will be like 100 ms vs. 200 ms or something like that.
>
> I don't particularly buy that argument. There are good reasons (like
> avoiding deadlocks, long transactions) to drop multiple tables
> in individual transactions.
> Not that I have a good plan to how to work around that though :(
Yeah, if you need to drop the tables one by one for some reason, you
can't get rid of the overhead this way :-(
OTOH in the example above the overhead is ~50%, i.e. 1.5ms / table with
a
single index. Each such associated relation (index, TOAST table, ...)
means
a relation that needs to be dropped and on my machine, once I reach ~5
relations there's almost no difference as the overhead is balanced by
the
gains.
Not sure how to fix that in an elegant way, though :-(
Tomas