Re: same query, two different approaches, vastly different performance

On Mon, Feb 13, 2012 at 9:52 PM, Greg Sabino Mullane

> When you do that prepare and execute, DBD::Pg is asking Postgres to
> create a prepared statement, such that it can send just the arguments,
> and not the full statement, each time execute() is called. You can
> force it to *not* do so by issuing:
>
> $dbh->{pg_server_prepare} = 0;
>
> You can also do this at the statement handle generation time: see the
> DBD::Pg docs for more information.
>

That's awesome. Here's the answer to the PK's other question:

The proposed patch to Postgres would cause plan selection to be deferred,
in case of LIKE <placeholder>, until after pg can look at the
placeholder(s), to see if it's anchored at the front. The resulting trick
pg would generate 2**n plans at prepare time, where n is the number of
placeholders that may or may not be anchored at the front. Extra extra
points for figuring out that '^'||<placeholder> will always be so anchored,
so it can use a sorted index, even though it might have to filter the
results from that. With such a hack in place, and turned on by default,
there would be one fewer situation where the pg_server_prepare attribute
could be left on.

-- 
on the outside of the bottom of the barrel, that's how much of an outlier
it is.