Re: [HACKERS] Including Snapshot Info with Indexes

On 10/23/07, Heikki Linnakangas <heikki(at)enterprisedb(dot)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
>