Re: [PERFORM] COUNT(*) again (was Re: Index/Function

Поиск
Список
Период
Сортировка
От Hannu Krosing
Тема Re: [PERFORM] COUNT(*) again (was Re: Index/Function
Дата
Msg-id 1065301140.2746.37.camel@fuji.krosing.net
обсуждение исходный текст
Ответ на COUNT(*) again (was Re: Index/Function organized table layout)  (Tom Lane <tgl@sss.pgh.pa.us>)
Ответы Re: [PERFORM] COUNT(*) again (was Re: Index/Function organized table layout)
Список pgsql-hackers
Tom Lane kirjutas L, 04.10.2003 kell 19:07:
> Hannu Krosing <hannu@tm.ee> writes:
> > Christopher Browne kirjutas R, 03.10.2003 kell 00:57:
> >> A while back I outlined how this would have to be done, and for it to
> >> be done efficiently, it would be anything BUT simple.
>
> > Could this be made a TODO item, perhaps with your attack plan.
>
> If I recall that discussion correctly, no one including Christopher
> thought the attack plan was actually reasonable.
>
> What this keeps coming down to is that an optimization that helps only
> COUNT(*)-of-one-table-with-no-WHERE-clause would be too expensive in
> development and maintenance effort to justify its existence.

Please read further in my email ;)

The point I was trying to make was that faster count(*)'s is just a side
effect. If we could (conditionally) keep visibility info in indexes,
then this would also solve the problem fo much more tricky question of
index-structured tables.

Count(*) is *not* the only query that could benefit from not needing to
go to actual data table for visibilty info, The much more needed case
would be the "inveres time series" type of queries, which would
otherways trash cache pages badly.

----------------------------
Hannu


В списке pgsql-hackers по дате отправления:

Предыдущее
От: Tom Lane
Дата:
Сообщение: Re: initdb
Следующее
От: Greg Stark
Дата:
Сообщение: Re: max_connections/shared_buffers (was Re: Beta4 Tag'd and Bundled ...)