From: | devik(at)cdi(dot)cz |
---|---|
To: | Philip Warner <pjw(at)rhyme(dot)com(dot)au> |
Cc: | Hannu Krosing <hannu(at)tm(dot)ee>, pgsql-hackers(at)postgresql(dot)org |
Subject: | Re: pgsql is 75 times faster with my new index scan |
Date: | 2000-09-26 11:49:41 |
Message-ID: | 39D08D55.B57416F9@cdi.cz |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | 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
From | Date | Subject | |
---|---|---|---|
Next Message | Danny | 2000-09-26 12:06:52 | Re: Re: [HACKERS] RFC - change of behaviour of pg_get_userbyid & pg_get_viewdef? |
Previous Message | Philip Warner | 2000-09-26 11:46:16 | Re: pgsql is 75 times faster with my new index scan |