From: | Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us> |
---|---|
To: | Bruce Momjian <pgman(at)candle(dot)pha(dot)pa(dot)us> |
Cc: | Matthias Urlichs <smurf(at)noris(dot)net>, Mike Mascari <mascarm(at)mascari(dot)com>, pgsql-hackers(at)postgresql(dot)org |
Subject: | Re: More Performance |
Date: | 2000-05-21 01:13:49 |
Message-ID: | 25715.958871629@sss.pgh.pa.us |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-general pgsql-hackers |
Bruce Momjian <pgman(at)candle(dot)pha(dot)pa(dot)us> writes:
>> What heap? The index is a b-tree in this case. Thus you should be able
>> to walk it and get the sorted result without ever touching the data
>> file.
> We can't read data from the index. It would be nice if we could, but we
> can't.
The reason we can't is that we don't store tuple validity data in
indexes. The index entry has the key value and a pointer to the tuple
in the main heap file, but we have to visit the tuple to find out
whether it's committed or dead. If we did otherwise, then committing or
killing tuples would be lots slower than it is, because we'd have to
find and mark all the index entries pointing at the tuple, not just the
tuple itself. It's a tradeoff... but we think it's a good one.
> I think we believe that there are very few cases where this
> would be win. Usually you need non-indexed data too.
Right, non-toy examples usually read additional data columns anyway.
regards, tom lane
From | Date | Subject | |
---|---|---|---|
Next Message | Bruce Momjian | 2000-05-21 01:57:50 | Re: Performance (was: The New Slashdot Setup (includes MySql server)) |
Previous Message | Tom Lane | 2000-05-20 21:44:45 | Re: Performance (was: The New Slashdot Setup (includes MySql server)) |
From | Date | Subject | |
---|---|---|---|
Next Message | Chris | 2000-05-21 01:28:13 | Re: Thus spoke SQL3 (on OO) |
Previous Message | Chris | 2000-05-21 00:55:34 | Re: OO Patch |