From: Jim C. Nasby <jnasby@pervasive.com>
To: Tom Lane <tgl@sss.pgh.pa.us>
Cc: Mark Kirkwood <markir@paradise.net.nz>
Cc: Markus Schaber <schabi@logix-tt.com>
Cc: pgsql-performance@postgresql.org
Subject: Re: merge>hash>loop
Date: Thu, 20 Apr 2006 11:27:32 -0500
Message-ID: <20060420162732.GX49405@pervasive.com> (raw)
In-Reply-To: <22250.1145424328@sss.pgh.pa.us>
References: <1145029009.3422.31.camel@spectre.intellivid.com>
<10000.1145031205@sss.pgh.pa.us>
<1145033149.3422.41.camel@spectre.intellivid.com>
<11035.1145033929@sss.pgh.pa.us>
<4444C4CF.2000106@logix-tt.com>
<20060418215238.GK49405@pervasive.com>
<19388.1145398946@sss.pgh.pa.us>
<20060418231552.GN49405@pervasive.com>
<4445C0EC.2060407@paradise.net.nz>
<22250.1145424328@sss.pgh.pa.us>
On Wed, Apr 19, 2006 at 01:25:28AM -0400, 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).
Very true. OTOH, it might not be unreasonable to periodically slog
through the buffers and store that information, perhaps once a minute,
or every X number of transactions.
I think a bigger issue is that we currently have no way to really
measure the effictiveness of the planner. Without that it's impossible
to come up with any real data on whether cost formula A is better or
worse than cost formula B. The only means I can think of for doing this
would be to measure estimated cost vs actual cost, but with the overhead
of EXPLAIN ANALYZE and other variables that might not prove terribly
practical. Maybe someone else has some ideas...
--
Jim C. Nasby, Sr. Engineering Consultant jnasby@pervasive.com
Pervasive Software http://pervasive.com work: 512-231-6117
vcard: http://jim.nasby.net/pervasive.vcf cell: 512-569-9461
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Reply to all the recipients using the --to and --cc options:
reply via email
To: pgsql-performance@postgresql.org
Cc: jnasby@pervasive.com, tgl@sss.pgh.pa.us, markir@paradise.net.nz, schabi@logix-tt.com
Subject: Re: merge>hash>loop
In-Reply-To: <20060420162732.GX49405@pervasive.com>
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
This inbox is served by DDX for PostgreSQL; see mirroring instructions
for how to clone and mirror all data and code used for this inbox