Re: Prepared statements considered harmful - Mailing list pgsql-hackers

From Zeugswetter Andreas DCP SD
Subject Re: Prepared statements considered harmful
Date
Msg-id E1539E0ED7043848906A8FF995BDA579014DBEBF@m0143.s-mxs.net
Whole thread Raw
In response to Re: Prepared statements considered harmful  (Peter Eisentraut <peter_e@gmx.net>)
List pgsql-hackers
> > I don't chime in very often, but I do think the refusal to
incorporate
> > hints into the planner system is fantastically stubborn and
> > nonsensical.
>
> What is actually fantastically nonsensical about this is that
> the issues I outlined about prepared statements would merely
> become worse if planner hints were used.  Then, you wouldn't
> only have to worry about plans that were created earlier
> during the session, you would be faced with plans that were
> created earlier during the application's development.  In
> general, the solutions to the prepared statement issues need
> to effect that the plans are created more often, not less often.

I have yet to see one of our partial Informix hints (where the planner
does it's
usual job only with one path with lowered/elevated costs) fall foul on
not anticipated change of underlying data.

Thus I don't buy the argument that hints are always bad.
Of course their use should be extremely rare and well thought out.
Most of the time sql tuning involves a concerted effort between the
programmer and a db performance expert, usually resulting in
rewritten sql or program logic without adding hints.

I can see arguments for hints the dba can set himself centrally on the
server,
but in my experience chances for substantial improvement are very
limited in that case.

Andreas


pgsql-hackers by date:

Previous
From: Michael Glaesemann
Date:
Subject: Re: [PATCHES] Interval aggregate regression failure
Next
From: Michael Glaesemann
Date:
Subject: Re: [PATCHES] Interval aggregate regression failure