Re: Simple join optimized badly? - Mailing list pgsql-performance

From Craig A. James
Subject Re: Simple join optimized badly?
Date
Msg-id 452B108C.7020703@modgraph-usa.com
Whole thread Raw
In response to Re: Simple join optimized badly?  (Brian Herlihy <btherl@yahoo.com.au>)
Responses Re: Simple join optimized badly?
List pgsql-performance
Brian Herlihy wrote:
> PG does support hints actually..
> The only thing is, the hints are expressed in an obscure, ad-hoc and
> implementation dependant language.
>
> For example, the "Don't use index X" hint (the one I used) can be accessed by
> replacing your index with an index on values derived from the actual index...

And then there's

    select ... from (select ... offset 0)

where the "offset 0" prevents any rewriting between the two levels of query.  This replaces joins and AND clauses where
theplanner makes the wrong choice of join order or filtering.  I grepped my code and found four of these (all
workaroundsfor the same underlying problem). 

Imagine I got run over by a train, and someone was reading my code.  Which would be easier for them to maintain: Code
withweird SQL, or code with sensible, well-written SQL and explicit hints?  Luckily for my (hypothetical, I hope)
successor,I put massive comments in my code explaining the strange SQL. 

The bad applications are ALREADY HERE.  And they're WORSE to maintain than if we had a formal hint language.  The
argumentthat hints lead to poor application is true.  But lack of hints leads to worse applications. 

Craig


pgsql-performance by date:

Previous
From: Brian Herlihy
Date:
Subject: Re: Simple join optimized badly?
Next
From: "Joshua D. Drake"
Date:
Subject: Re: Simple join optimized badly?