Re: pgsql is 75 times faster with my new index scan - Mailing list pgsql-hackers

From devik@cdi.cz
Subject Re: pgsql is 75 times faster with my new index scan
Date
Msg-id 39D08D55.B57416F9@cdi.cz
Whole thread Raw
In response to pgsql is 75 times faster with my new index scan  (devik@cdi.cz)
List pgsql-hackers
> That would be great, or alternatively, an attribute on the index?

yes attribute would be nice.

> 
> Dec RDB offers this kind of feature, and it suffers from deadlocking
> problems because of index node vs. row locking as well as high lock
> contention when updating indexed data, so it's not just the cost of doing
> the updates. I definitely thinks it's a good feature to implement, if

where is the reason of contention/ddlock ? We (or you?) only need to
update index tuple's header data (like TX min/max) and key is
untouched. So that all index scans should be able to go without
disturbing. Index page should be locked in memory only for few
ticks during actual memcpy to page.

BTW: IMHO when WAL become functional, need we still multi versioned
tuples in heap ? Why don't just version tuples on WAL log and add
them during scans ?

devik



pgsql-hackers by date:

Previous
From: devik@cdi.cz
Date:
Subject: Re: pgsql is 75 times faster with my new index scan
Next
From: Thomas Lockhart
Date:
Subject: Re: [BUGS] 7.0.2 source rpm failed to compile