On 10/23/07, Heikki Linnakangas <[EMAIL PROTECTED]> 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 >
