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. 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 ---------------------------(end of broadcast)--------------------------- TIP 2: Don't 'kill -9' the postmaster
