Re: [HACKERS] Slow count(*) again...

Поиск
Список
Период
Сортировка
От Bruce Momjian
Тема Re: [HACKERS] Slow count(*) again...
Дата
Msg-id 201102031656.p13Guug09499@momjian.us
обсуждение исходный текст
Ответ на Re: [HACKERS] Slow count(*) again...  (Mladen Gogala <mladen.gogala@vmsinfo.com>)
Ответы Re: [HACKERS] Slow count(*) again...  (Robert Haas <robertmhaas@gmail.com>)
Список 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 по дате отправления:

Предыдущее
От: Mladen Gogala
Дата:
Сообщение: Re: [HACKERS] Slow count(*) again...
Следующее
От: Bruce Momjian
Дата:
Сообщение: Re: [HACKERS] Slow count(*) again...