Re: [HACKERS] Slow count(*) again... - Mailing list pgsql-performance

From Kevin Grittner
Subject Re: [HACKERS] Slow count(*) again...
Date
Msg-id 4D4ADF42020000250003A34C@gw.wicourts.gov
Whole thread Raw
In response to Re: [HACKERS] Slow count(*) again...  (Mladen Gogala <mladen.gogala@vmsinfo.com>)
Responses Re: [HACKERS] Slow count(*) again...  (Mladen Gogala <mladen.gogala@vmsinfo.com>)
List pgsql-performance
Mladen Gogala <mladen.gogala@vmsinfo.com> wrote:

> Maybe we can agree to remove that ridiculous "we don't want hints"
> note from Postgresql wiki?

I'd be against that.  This is rehashed less frequently since that
went in.  Less wasted time and bandwidth with it there.

> That would make it look less like , hmph, philosophical issue and
> more "not yet implemented" issue,

Exactly what we don't want.

> especially if we have in mind that hints are already here, in the
> form of "enable_<method>" switches.

Those aren't intended as hints for production use.  They're there
for diagnostic purposes.  In our shop we've never used any of those
flags in production.

That said, there are ways to force an optimization barrier when
needed, which I have occasionally seen people find useful.  And
there are sometimes provably logically equivalent ways to write a
query which result in different plans with different performance.
It's rare that someone presents a poorly performing query on the
list and doesn't get a satisfactory resolution fairly quickly -- if
they present sufficient detail and work nicely with others who are
volunteering their time to help.

-Kevin

pgsql-performance by date:

Previous
From: Josh Berkus
Date:
Subject: Re: [HACKERS] Slow count(*) again...
Next
From: Noah Misch
Date:
Subject: Re: Exhaustive list of what takes what locks