Skip site navigation (1) Skip section navigation (2)

Re: [HACKERS] Including Snapshot Info with Indexes

From: "Gokulakannan Somasundaram" <gokul007(at)gmail(dot)com>
To: "Heikki Linnakangas" <heikki(at)enterprisedb(dot)com>
Cc: pgsql-patches(at)postgresql(dot)org, "Luke Lonergan" <llonergan(at)greenplum(dot)com>, "Gregory Stark" <stark(at)enterprisedb(dot)com>, "Tom Lane" <tgl(at)sss(dot)pgh(dot)pa(dot)us>, "Andreas Joseph Krogh" <andreak(at)officenet(dot)no>, "Hannu Krosing" <hannu(at)skype(dot)net>, pgsql-hackers(at)postgresql(dot)org
Subject: Re: [HACKERS] Including Snapshot Info with Indexes
Date: 2007-10-23 11:08:50
Message-ID: 9362e74e0710230408i6abb2f88p477144756b563e0b@mail.gmail.com (view raw or flat)
Thread:
Lists: pgsql-hackerspgsql-patches
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
>

In response to

pgsql-hackers by date

Next:From: Heikki LinnakangasDate: 2007-10-23 11:11:49
Subject: Re: [PATCHES] Including Snapshot Info with Indexes
Previous:From: Heikki LinnakangasDate: 2007-10-23 10:30:04
Subject: Re: [HACKERS] Including Snapshot Info with Indexes

pgsql-patches by date

Next:From: Heikki LinnakangasDate: 2007-10-23 11:11:49
Subject: Re: [PATCHES] Including Snapshot Info with Indexes
Previous:From: Heikki LinnakangasDate: 2007-10-23 10:30:04
Subject: Re: [HACKERS] Including Snapshot Info with Indexes

Privacy Policy | About PostgreSQL
Copyright © 1996-2014 The PostgreSQL Global Development Group