Re: Avoiding bad prepared-statement plans. - Mailing list pgsql-hackers

From Tom Lane
Subject Re: Avoiding bad prepared-statement plans.
Date
Msg-id 8170.1267228986@sss.pgh.pa.us
Whole thread Raw
In response to Re: Avoiding bad prepared-statement plans.  (Robert Haas <robertmhaas@gmail.com>)
Responses Re: Avoiding bad prepared-statement plans.  (Mark Mielke <mark@mark.mielke.cc>)
Re: Avoiding bad prepared-statement plans.  (Robert Haas <robertmhaas@gmail.com>)
List pgsql-hackers
Robert Haas <robertmhaas@gmail.com> writes:
> Basically, what I really want here is some kind of keyword or other
> syntax that I can stick into a PL/pgsql query that requests a replan
> on every execution.

Wouldn't it be better if it just did the right thing automatically?

The sort of heuristic I'm envisioning would essentially do "replan every
time" for some number of executions, and give up only if it noticed that
it wasn't getting anything better than the generic plan.  So you'd have
a fixed maximum overhead per session when the custom plan was useless,
and the Right Thing when it wasn't.
        regards, tom lane


pgsql-hackers by date:

Previous
From: Greg Smith
Date:
Subject: Re: Hot Standby query cancellation and Streaming Replication integration
Next
From: Greg Smith
Date:
Subject: Re: Hot Standby query cancellation and Streaming Replication integration