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

From Bruce Momjian
Subject Re: [HACKERS] Slow count(*) again...
Date
Msg-id 201102031656.p13Guug09499@momjian.us
Whole thread Raw
In response to Re: [HACKERS] Slow count(*) again...  (Mladen Gogala <mladen.gogala@vmsinfo.com>)
Responses Re: [HACKERS] Slow count(*) again...
List pgsql-performance
Mladen Gogala wrote:
> Greg Smith wrote:
> > Mladen Gogala wrote:
> >
> >> The techies at big companies are the guys who will or will not make it
> >> happen. And these guys are not beginners.  Appeasing them may actually
> >> go a long way.
> >>
> >
> > The PostgreSQL community isn't real big on appeasing people if it's at
> > the expense of robustness or correctness, and this issue falls into that
> > category.
>
> With all due respect, I don't see how does the issue of hints fall into
> this category? As I explained, the mechanisms are already there, they're
> just not elegant enough. The verb "appease" doesn't convey the meaning
> that I had in mind quite correctly. The phrase "target population" would
> have  described what I wanted to say in a much better way .

The settings are currently there to better model the real world
(random_page_cost), or for testing (enable_seqscan).  They are not there
to force certain plans.  They can be used for that, but that is not
their purpose and they would not have been added if that was their
purpose.

--
  Bruce Momjian  <bruce@momjian.us>        http://momjian.us
  EnterpriseDB                             http://enterprisedb.com

  + It's impossible for everything to be true. +

pgsql-performance by date:

Previous
From: Mladen Gogala
Date:
Subject: Re: [HACKERS] Slow count(*) again...
Next
From: Bruce Momjian
Date:
Subject: Re: [HACKERS] Slow count(*) again...