Re: the big picture for index-only scans

Поиск
Список
Период
Сортировка
От Greg Stark
Тема Re: the big picture for index-only scans
Дата
Msg-id BANLkTi=XvEA24K=LNNUg=SwyrxK-p-U0nw@mail.gmail.com
обсуждение исходный текст
Ответ на Re: the big picture for index-only scans  ("Kevin Grittner" <Kevin.Grittner@wicourts.gov>)
Ответы Re: the big picture for index-only scans
Re: the big picture for index-only scans
Re: the big picture for index-only scans
Список pgsql-hackers
On Wed, May 11, 2011 at 12:14 AM, Kevin Grittner
<Kevin.Grittner@wicourts.gov> wrote:
> The problem is that there are regular and fairly frequent complaints
> on the list about queries which run slower than people expect
>

To be fair about 3/4 of them were actually complaining about the lack
of some global materialized cache of the aggregate value. Covering
index-only scans are only going to be a linear speedup no matter how
large the factor it's not going to turn select count(*) into a O(1)
operation.

I support the idea of thinking of this as an optimization. But I don't
think there's much question. If we can avoid doing the i/o on the heap
that's an obvious and huge win. Sure the costs of maintaining the vm
need to be measured against the gains but it we don't know what those
costs are yet and whoever works on it will be well aware of that
balance.

On a separate note though, Simon, I don't know what you mean by "we
normally start with a problem". It's an free software project and
people are free to work on whatever interests them whether that's
because it solves a problem they have, helps a client who's paying
them, or just because it's of academic interest to them. We don't
always take their patches if they aren't of general interest but
people propose all kinds of crazy experimental ideas all the time.

-- 
greg


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

Предыдущее
От: Bruce Momjian
Дата:
Сообщение: Re: Re: [BUGS] BUG #5957: createdb with description and md5 auth forces to provide password twice
Следующее
От: Bruce Momjian
Дата:
Сообщение: Re: postgresql.conf error checking strategy