I doubt everyone would like trading query speed for insert/update
speed plus index size
If he is scanning through the entire index, he could do a sequential
scan of the table, grab all the tid transaction status values, and use
those when viewing the index. No need to
Bruce Momjian wrote:
I doubt everyone would like trading query speed for insert/update
speed plus index size
If he is scanning through the entire index, he could do a sequential
scan of the table, grab all the tid transaction status values, and use
those when viewing the
those when viewing the index. No need to store/update the transaction
status in the index that way.
Huh ? How ? It is how you do it now. Do you expect
load several milion transaction statuses into memory,
then scan index and lookup these values ?
Missed I something ?
Bruce Momjian wrote:
I doubt everyone would like trading query speed for insert/update
speed plus index size
If he is scanning through the entire index, he could do a sequential
scan of the table, grab all the tid transaction status values, and use
those when viewing
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
If he is scanning
The it will be MUCH faster to create secondary index which
is much smaller than heap and use values from it.
Agreed. But this will add 16 bytes (2 xid + 2 cid) to size of btitems.
Currently, total size of btitem for 2-int4 key index is 16 bytes =
new feature will double size of index and
Why not implement *true* CLUSTER?
With cluster, all heap tuples will be in cluster index.
It would be nice. It's pity that pg AMs are not general.
There is no simple way to use btree instead of heap. But
it would help.
But using values from index is good idea too because you
can have table
What is *true* CLUSTER ?
'grep CLUSTER' over the latest SQL standards gives back nothing.
storing data in b-tree instead of heap for example.
And update *entire* heap after addition new index?!
I guess that this should be done even for limited number of
indices' TIDs in a heap tuple ?
Why not implement *true* CLUSTER?
With cluster, all heap tuples will be in cluster index.
It would be nice. It's pity that pg AMs are not general.
There is no simple way to use btree instead of heap. But
it would help.
But using values from index is good idea too because you
can have
It was discussed several times for btree - add heap tid to
index key and you'll scan index for particulare tuple much faster.
good idea :) Why don't just to use tid ALWAYS as last part of key ?
When btree code sees equal keys then it will compare tids ?
Would not be better to use oids ?
* [EMAIL PROTECTED] [EMAIL PROTECTED] [000926 02:33] wrote:
Hello,
I recently spoke about extending index scan to be able
to take data directly from index pages.
[snip]
Is someone interested in this ??
Considering the speedup, I sure as hell am interested. :)
When are we going to have
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
The last step could be done in two ways. First by limiting
number of indices for one table we can store coresponding
indices' TIDs in each heap tuple. The update is then simple
taking one disk write.
Why limit it ? One could just save an tid array in each tuple .
And update *entire*
Why not implement *true* CLUSTER?
With cluster, all heap tuples will be in cluster index.
Vadim
-Original Message-
From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED]]
Sent: Tuesday, September 26, 2000 2:15 AM
To: [EMAIL PROTECTED]
Subject: [HACKERS] pgsql is 75 times faster with my
14 matches
Mail list logo
