On 30.12.2012 04:03, Robert Haas wrote:
> On Sun, Dec 23, 2012 at 8:41 PM, Tomas Vondra <t...@fuzzy.cz> wrote:
>> Attached is a patch with fixed handling of temporary relations. I've
>> chosen to keep the logic in DropRelFileNodeAllBuffers and rather do a
>> local copy without the local relations.
>
> This looks pretty good, although it needs some cleanup for coding
> style. And I think BSEARCH_LIMIT cuts a bit too broadly as a name for
> the constant.
I thought I followed the conding style - which guidelines have I broken?
I agree that BSEARCH_LIMIT is a bit too short / not exactly descriptive.
What alternative would you suggest?
> Granted that we can't decide on an exact value for BSEARCH_LIMIT, is
> there any data to indicate that 10 is at least an approximately
> correct value?
I've presented some relevant test results on 17/12, here is the
interesting part:
# indexes 0 1 2 3 4 5 6 7 8 9 10 11
--------------------------------------------------------------
unpatched 16 28 40 52 63 75 87 99 110 121 135 147
v3.1 33 43 46 56 58 60 63 72 75 76 79 80
v3.3 16 20 23 25 29 33 36 40 44 47 79 82
where v3.1 is a patch doing bsearch all the time, v3.3 uses the
BSEARCH_LIMIT optimization. A few observations:
(a) the v3.3 is consistently faster, and the time increases by about
3.5 second for each index
(b) the v3.1 is slower at the beginning, but at the end the time
increases much slower (~1.5 sec/index)
(c) once we get to 4 indexes (5 relations in total), both 3.1 and 3.3
are faster than the current code
(d) in case of v3.3, there's a step increase between 9 and 10 indexes
(because for 10 indexes the code chooses the bsearch path), but even
after this increase both versions are faster than the original code
Given (b) and (c) both patches should meet at about 24 (so we might
increase the BSEARCH_LIMIT e.g. to 25). It's a bit difficult to predict
the behaviour on different machines (different CPUs, different amounts
of shared_buffers etc.) but I guess this is safe.
But even if we stick to the current value (10) I believe it's safe and
both versions are much faster than the current code.
regards
Tomas
--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-hackers
