To: "Jim C. Nasby" <jim@nasby.net>
cc: Josh Berkus <josh@agliodbs.com>, pgsql-hackers@postgresql.org,
	pgsql-performance@postgresql.org
Subject: Re: [HACKERS] Hints proposal 
In-reply-to: <20061013233615.GA381@nasby.net> 
References: <20061012151439.GT28647@nasby.net>
	<200610121358.22739.josh@agliodbs.com>
	<20061013161614.GT28647@nasby.net>
	<200610131557.24420.josh@agliodbs.com>
	<20061013233615.GA381@nasby.net>
Comments: In-reply-to "Jim C. Nasby" <jim@nasby.net>
	message dated "Fri, 13 Oct 2006 18:36:15 -0500"
Date: Sat, 14 Oct 2006 00:19:46 -0400
Message-ID: <25999.1160799586@sss.pgh.pa.us>
From: Tom Lane <tgl@sss.pgh.pa.us>

"Jim C. Nasby" <jim@nasby.net> writes:
> Let me clarify, because that's not what I meant. Right now, there's not
> even a shadow of a design for anything else, and this is a tough nut to
> crack.

I think you are not exactly measuring on a level playing field.  On the
textually-embedded-hints side, I see a very handwavy suggestion of a
syntax and absolutely nothing about how it might be implemented --- in
particular, nothing about how the information would be transmitted
through to the planner, and nothing about exactly how the planner would
use it if it had it.  (No, I don't think "the planner will obey the
hints" is an implementation sketch.)  On the other side, the concept of
system catalog(s) containing overrides for statistical or costing
estimates is pretty handwavy too, but at least it's perfectly clear
where it would plug into the planner: before running one of the current
stats estimation or costing functions, we'd look for a matching override
command in the catalogs.  The main question seems to be what we'd like
to be able to match on ... but that doesn't sound amazingly harder than
specifying what an embedded hint does.

IMO a textual hint facility will actually require *more* infrastructure
code to be written than what's being suggested for alternatives.

			regards, tom lane