On Tue, 2005-02-15 at 02:38 -0500, Greg Stark wrote:
> I don't know what software you work with but the Postgres source is far and
> away the best documented source I've had the pleasure to read.
I agree the PostgreSQL source is very nice (for the most part), but I
think there could be more higher
> And the user maintenance of updating those hints for every release of
> PostgreSQL as we improve the database engine.
I don't think so. Basically an optimizer hint simply raises or lowers the cost
of an index, mandates a certain join order, allows or disallows a seq scan ...
Imho it is not so
Although this is all true, consider that adding hints will mean that the
Pg developers *never* get bug reports to drive the optimizer improvement
process. This will have the effect of stagnating its development. I
think this would be a bad thing :-)
As an aside note that DB2 UDB does not let you hi
Neil Conway <[EMAIL PROTECTED]> writes:
> - good, thorough documentation of the internals (naturally this would
> help attract OSS developers as well)
I don't know what software you work with but the Postgres source is far and
away the best documented source I've had the pleasure to read. I thin
> [EMAIL PROTECTED] writes:
>> I think that is sort of arrogant. Look at Oracle, you can give the
>> planner
>> hints in the form of comments.
>
> Arrogant or not, that's the general view of the people who work on the
> planner.
>
> The real issue is not so much whether the planner will always get
On Mon, 2005-02-14 at 22:56 -0500, Bruce Momjian wrote:
> And the user maintenance of updating those hints for every release of
> PostgreSQL as we improve the database engine.
... and maintaining those hints as the data changes over time.
But I think this thread has been hijacked toward a subject
Tom Lane wrote:
> [EMAIL PROTECTED] writes:
> > I think that is sort of arrogant. Look at Oracle, you can give the planner
> > hints in the form of comments.
>
> Arrogant or not, that's the general view of the people who work on the
> planner.
>
> The real issue is not so much whether the planner
[EMAIL PROTECTED] writes:
> I think that is sort of arrogant. Look at Oracle, you can give the planner
> hints in the form of comments.
Arrogant or not, that's the general view of the people who work on the
planner.
The real issue is not so much whether the planner will always get things
right --
> On Thu, 2005-02-10 at 14:37 -0500, Bruce Momjian wrote:
>> No, we feel that is of limited value. If the optimizer isn't doing
>> things properly, we will fix it.
>
> I agree that improving the optimizer is the right answer for normal
> usage, so I can't get excited about query-level plan hints,
On Thu, 2005-02-10 at 14:37 -0500, Bruce Momjian wrote:
> No, we feel that is of limited value. If the optimizer isn't doing
> things properly, we will fix it.
I agree that improving the optimizer is the right answer for normal
usage, so I can't get excited about query-level plan hints, but I can
Hicham
For your experiments (VLDB ? :-) your best bet of specifically bolting
on a plan (if you can't convince the optimizer to do the right thing)
is to hack it in the query planner.
I've done similar hacks in the past, but only in the TelegraphCQ code
and not in PostgreSQL.
--
Pip-pip
Sail
Hicham G. Elmongui wrote:
> Is there a way to bypass the optimizer and to specify a plan to be executed?
>
> Something like:
>
>
>
> Limit
> -> Nested Loop
> -> Nested Loop
> -> Seq Scan on tab00 t00
> -> Index Scan using tab03_pkey on tab03 t03
> I
Is there a way to bypass the optimizer and to specify a plan to be executed?
Something like:
Limit
-> Nested Loop
-> Nested Loop
-> Seq Scan on tab00 t00
-> Index Scan using tab03_pkey on tab03 t03
Index Cond: ("outer".id = t03.id)
-> Index Sca
13 matches
Mail list logo
