Re: [PERFORM] Hints proposal - Mailing list pgsql-hackers

From Merlin Moncure
Subject Re: [PERFORM] Hints proposal
Date
Msg-id b42b73150610120922x53bbc14atd9591f06f6e4e274@mail.gmail.com
Whole thread Raw
In response to Re: [PERFORM] Hints proposal  (Tom Lane <tgl@sss.pgh.pa.us>)
List pgsql-hackers
On 10/12/06, Tom Lane <tgl@sss.pgh.pa.us> wrote:
> [ This is off-topic for -performance, please continue the thread in
> -hackers ]

> This proposal seems to deliberately ignore every point that has been
> made *against* doing things that way.  It doesn't separate the hints
> from the queries, it doesn't focus on fixing the statistical or cost
> misestimates that are at the heart of the issue, and it takes no account
> of the problem of hints being obsoleted by system improvements.

what about extending the domain system so that we can put in ranges
that override the statistics or (imo much more importantly) provide
information when the planner would have to restort to a guess. my case
for this is prepared statements with a parameterized limit clause.

prepare foo(l int) as select * from bar limit $1;

maybe:
create domain foo_lmt as int hint 1; -- probably needs to be fleshed out
prepare foo(l foolmt) as select * from bar limit $1;

this says: "if you have to guess me, please use this"

what I like about this over previous attempts to persuade you is the
grammar changes are localized and also imo future proofed. planner can
ignore the hints if they are not appropriate for the oparation.

merlin

pgsql-hackers by date:

Previous
From: Tom Lane
Date:
Subject: SQL functions, INSERT/UPDATE/DELETE RETURNING, and triggers
Next
From: "Jim C. Nasby"
Date:
Subject: Re: [PERFORM] Hints proposal