Re: merge>hash>loop - Mailing list pgsql-performance

From Tom Lane
Subject Re: merge>hash>loop
Date
Msg-id 22250.1145424328@sss.pgh.pa.us
Whole thread Raw
In response to Re: merge>hash>loop  (Mark Kirkwood <markir@paradise.net.nz>)
Responses Re: merge>hash>loop
Re: merge>hash>loop
List pgsql-performance
Mark Kirkwood <markir@paradise.net.nz> writes:
> Jim C. Nasby wrote:
>> Good point. :/ I'm guessing there's no easy way to see how many blocks
>> for a given relation are in shared memory, either...

> contrib/pg_buffercache will tell you this -

I think the key word in Jim's comment was "easy", ie, cheap.  Grovelling
through many thousands of buffers to count the matches to a given
relation doesn't sound appetizing, especially not if it gets done over
again several times during each query-planning cycle.  Trying to keep
centralized counts somewhere would be even worse (because of locking/
contention issues).

            regards, tom lane

pgsql-performance by date:

Previous
From: "Jim C. Nasby"
Date:
Subject: Re: merge>hash>loop
Next
From: Mark Kirkwood
Date:
Subject: Re: Blocks read for index scans