Andres Freund <and...@2ndquadrant.com> writes:
> The biggest concern previously were some benchmarks. I'm not entirely
> sure where to get a good testcase for this that's not completely
> artificial - most simpler testcases don't pin many buffers.
FWIW, I think that's by design; we don't ever want to pin more than one
buffer per relation+index in use in a given query. You could certainly
build complicated queries joining many tables in order to push up the
number of pinned buffers, but whether buffer pin manipulations would be
the bottleneck in such cases is pretty dubious.
I would say that the issue most deserving of performance testing is your
sizing of the linear-search array --- it's not obvious that 8 is a good
size.
Another thing to think about: a way to get to larger numbers of pinned
buffers without especially-complex queries is to have nested queries,
such as SQL queries inside plpgsql functions inside outer queries.
Does the patch logic take any advantage of the locality-of-reference
that will occur in such scenarios?
regards, tom lane
--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-hackers
