Re: [PATCHES] Including Snapshot Info with Indexes

Поиск
Список
Период
Сортировка
От Gokulakannan Somasundaram
Тема Re: [PATCHES] Including Snapshot Info with Indexes
Дата
Msg-id 9362e74e0710230408i6abb2f88p477144756b563e0b@mail.gmail.com
обсуждение исходный текст
Ответ на Re: [PATCHES] Including Snapshot Info with Indexes  ("Heikki Linnakangas" <heikki@enterprisedb.com>)
Список pgsql-hackers


On 10/23/07, Heikki Linnakangas <heikki@enterprisedb.com> wrote:
Gokulakannan Somasundaram wrote:
>     I would like to present the first patch. It currently has the following
> restrictions
> a) It does not support any functional indexes.
> b) It supports queries like select count(1) from table where (restrictions
> from indexed columns), but it does not support select count(1) from table.

An interesting question is how to represent tuples coming from the index
in the executor. I see that you didn't address that at all, because you
only support "COUNT(1)", and not things like "SELECT column FROM table
WHERE id = ?" where you actually return datums from the index. But
that's something that we have to think about in the DSM approach as well.
That's addressed as well.

One solution is to form a heap tuple, using the datums from the index,
with the attributes that are not used in the query replaced with NULLs.
That seems simple, but I don't think it'll work with expression indexes,
when you do something like "SELECT length(column) FROM table WHERE id =
?", and there's an index on (id, length(column)).

> I have also enabled the display of Logical Reads. In order to see that, set
> log_statement_stats on.

You should start benchmarking, to verify that you're really getting the
kind of speed up you're looking for, before you spend any more effort on
that. Reduction in logical reads alone isn't enough. Remember that for a
big change like that, the gain has to be big as well.

As a first test, I'd like to see results from SELECTs on different sized
tables. On tables that fit in cache, and on tables that don't. Tables
large enough that the index doesn't fit in cache. And as a special case,
on a table just the right size that a normal index fits in cache, but a
thick one doesn't.

--
  Heikki Linnakangas
  EnterpriseDB   http://www.enterprisedb.com

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

Предыдущее
От: "Heikki Linnakangas"
Дата:
Сообщение: Re: [PATCHES] Including Snapshot Info with Indexes
Следующее
От: "Heikki Linnakangas"
Дата:
Сообщение: Re: [PATCHES] Including Snapshot Info with Indexes