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

From Mark Kirkwood
Subject Re: merge>hash>loop
Date
Msg-id 4445CB8E.5020800@paradise.net.nz
Whole thread Raw
In response to Re: merge>hash>loop  (Tom Lane <tgl@sss.pgh.pa.us>)
List pgsql-performance
Tom Lane wrote:
> 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).
>

Yeah - not sensible for a transaction oriented system - might be ok for
DSS tho.

Cheers

mark

pgsql-performance by date:

Previous
From: Mark Kirkwood
Date:
Subject: Re: Blocks read for index scans
Next
From: Theo Kramer
Date:
Subject: Re: Multicolumn order by