> 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 us
> > > > 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 ?
> > > Miss
> > 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 store/upda
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
> > > 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 t
> > 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
> > 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 i
> > question is whether we need it for hash indices. it is definitely
> > good for btree as they support range retrieval. hash ind. doesn't
> > it so I wouldn't implement it for them.
>
> We need in fast heap tuple --> index tuple lookup for overwriting
> storage manager anyway...
oh .. there w
> > 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
> > 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
> c
> 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
> 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 wi
"Mikheev, Vadim" wrote:
>
> Why not implement *true* CLUSTER?
> With cluster, all heap tuples will be in cluster index.
>
What is *true* CLUSTER ?
'grep CLUSTER' over the latest SQL standards gives back nothing.
> > > The last step could be done in two ways. First by limiting
> > > number of
> > Indice's TIDs are transient.
> > Isn't it useless to store indice's TIDs ?
>
> but yes Hiroshi is right. Index TID is transient. I first looked
> into pg sources two weeks ago so I have still holes in my knowledge.
> So that only solution is to traverse it ..
It was discussed several times f
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
> > 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 *
> > > 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 .
b
> 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 ju
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
> s
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
[EMAIL PROTECTED] wrote:
>
> Hello,
> I recently spoke about extending index scan to be able
> to take data directly from index pages. I wanted to know
> whether should I spend my time and implement it.
> So that I hacked last pgsql a bit to use proposed scan
> mode and did some measurements (see
* [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 ha
Hello,
I recently spoke about extending index scan to be able
to take data directly from index pages. I wanted to know
whether should I spend my time and implement it.
So that I hacked last pgsql a bit to use proposed scan
mode and did some measurements (see bellow). Measurements
was done on (id i
23 matches
Mail list logo
