From: | Philip Warner <pjw(at)rhyme(dot)com(dot)au> |
---|---|
To: | Hannu Krosing <hannu(at)tm(dot)ee>, devik(at)cdi(dot)cz |
Cc: | pgsql-hackers(at)postgresql(dot)org |
Subject: | Re: pgsql is 75 times faster with my new index scan |
Date: | 2000-09-26 11:46:16 |
Message-ID: | 3.0.5.32.20000926214616.02eda100@mail.rhyme.com.au |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-hackers |
At 12:28 26/09/00 +0300, Hannu Krosing wrote:
>> TODO:
>> - add HeapTupleHeaderData into each IndexTupleData
>> - change code to reflect above
>> - when deleting-updating heap then also update tuples'
>> HeapTupleHeaderData in indices
>
>I doubt everyone would like trading query speed for insert/update
>speed plus index size
Anybody who has a high enquiry:update ratio would, I think. And that will
be most people, especially web people.
>Perhaps this could be implemented as a special type of index which
>you must explicitly specify at create time ?
That would be great, or alternatively, an attribute on the index?
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
possible, but making it optional would be wise.
----------------------------------------------------------------
Philip Warner | __---_____
Albatross Consulting Pty. Ltd. |----/ - \
(A.B.N. 75 008 659 498) | /(@) ______---_
Tel: (+61) 0500 83 82 81 | _________ \
Fax: (+61) 0500 83 82 82 | ___________ |
Http://www.rhyme.com.au | / \|
| --________--
PGP key available upon request, | /
and from pgp5.ai.mit.edu:11371 |/
From | Date | Subject | |
---|---|---|---|
Next Message | devik | 2000-09-26 11:49:41 | Re: pgsql is 75 times faster with my new index scan |
Previous Message | devik | 2000-09-26 11:13:40 | Re: pgsql is 75 times faster with my new index scan |