Peter Geoghegan <> writes:
> On Thu, Jan 30, 2014 at 9:57 AM, Tom Lane <> wrote:
>> BTW ... it occurs to me to wonder if it'd be feasible to keep the
>> query-texts file mmap'd in each backend, thereby reducing the overhead
>> to write a new text to about the cost of a memcpy, and eliminating the
>> read cost in pg_stat_statements() altogether.  It's most likely not worth
>> the trouble; but if a more-realistic benchmark test shows that we actually
>> have a performance issue there, that might be a way out without giving up
>> the functional advantages of Peter's patch.

> There could be a worst case for that scheme too, plus we'd have to
> figure out how to make in work with windows, which in the case of
> mmap() is not a sunk cost AFAIK. I'm skeptical of the benefit of
> pursuing that.

Well, it'd be something like #ifdef HAVE_MMAP then use mmap, else
use what's there today.  But I agree that it's not something to pursue
unless we see a more credible demonstration of a problem.  Presumably
any such code would have to be prepared to remap if the file grows
larger than it initially allowed for; and that would be complicated
and perhaps have unwanted failure modes.

> In reality, actual applications
> could hardly be further from the perfectly uniform distribution of
> distinct queries presented here.

Yeah, I made the same point in different words.  I think any realistic
comparison of this code to what we had before needs to measure a workload
with a more plausible query frequency distribution.

                        regards, tom lane

Sent via pgsql-hackers mailing list (
To make changes to your subscription:

Reply via email to