On Nov 25, 2008, at 7:06 PM, Gregory Stark wrote:
>> The thought occurs to me that we're looking at this from the
>> wrong side of the
>> coin. I've never, ever seen query plan time pose a problem with
>> Postgres, even
>> without using prepared statements.
>
> I certainly have seen plan times be a problem. I wonder if you have
> too and
> just didn't realize it. With a default_stats_target of 1000 you'll
> have
> hundreds of kilobytes of data to slog through to plan a moderately
> complex
> query with a few text columns. Forget about prepared queries, I've
> seen plan
> times be unusable for ad-hoc interactive queries before.
Can you provide any examples?
And no, I've never seen a system where a few milliseconds of plan
time difference would pose a problem. I'm not saying they don't
exist, only that I haven't seen them (including 2 years working as a
consultant).
I'll also make the argument that anyone with a system that does have
those kind of requirements will have also needed to actually tune
their config, and tune it well. I can't see them being bothered by
having to set one more parameter. There are a lot of systems that are
being impacted by our ultra-low stats target, and a lot of those
don't necessarily need a lot of hand tuning beyond the stats target.
--
Decibel!, aka Jim C. Nasby, Database Architect decibel@decibel.org
Give your computer some brain candy! www.distributed.net Team #1828