Re: An Idea for planner hints - Mailing list pgsql-hackers

From Jim C. Nasby
Subject Re: An Idea for planner hints
Date
Msg-id 20060815172018.GX27928@pervasive.com
Whole thread Raw
In response to Re: An Idea for planner hints  (Peter Eisentraut <peter_e@gmx.net>)
Responses Re: An Idea for planner hints  (Peter Eisentraut <peter_e@gmx.net>)
List pgsql-hackers
On Tue, Aug 15, 2006 at 07:00:49PM +0200, Peter Eisentraut wrote:
> AgentM wrote:
> > Couldn't the session be explicitly transferred into a special
> > analysis mode? Explain analyze could run on every query implicitly
> > and point out time and row count discrepancies as HINTs. Multi-column
> > joins, for example, could be pointed out and display whether or not
> > there are related indexes.
> 
> Meet EXPLAIN ANALYZE.

Which does no good for apps that you don't control the code on. Even if
you do control the code, you have to find a way to stick EXPLAIN ANALYZE
in  front of every query, and figure out how to deal with what's comming
back. There's definately use cases where EXPLAIN ANALYZE isn't a very
good tool.

Going back to the original discussion though, there's no reason this
needs to involve EXPLAIN ANALYZE. All we want to know is what columns
the planner is dealing with as a set rather than individually. Logging
that information someplace need not be anywhere near as invasive as
EXPLAIN [ANALYZE]. One possibility is spewing out table/column
names/OIDs to a logfile in a tab-delimited format that can easily be
pulled back into the database and analyzed.
-- 
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


pgsql-hackers by date:

Previous
From: "Jim C. Nasby"
Date:
Subject: Re: [PATCHES] Forcing current WAL file to be archived
Next
From: Peter Eisentraut
Date:
Subject: Re: An Idea for planner hints