Re: [RFC, POC] Don't require a NBuffer sized PrivateRefCount array of local buffer pins

From: Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us>
To: Andres Freund <andres(at)2ndquadrant(dot)com>
Cc: pgsql-hackers(at)postgresql(dot)org
Subject: Re: [RFC, POC] Don't require a NBuffer sized PrivateRefCount array of local buffer pins
Date: 2014-08-27 02:19:47
Message-ID: 16762.1409105987@sss.pgh.pa.us
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-hackers

Andres Freund <andres(at)2ndquadrant(dot)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

In response to

Responses

Browse pgsql-hackers by date

  From Date Subject
Next Message Peter Eisentraut 2014-08-27 02:33:22 Re: alter user set local_preload_libraries.
Previous Message Etsuro Fujita 2014-08-27 02:15:35 Re: Compute attr_needed for child relations (was Re: inherit support for foreign tables)