On Tue, Oct 11, 2011 at 4:21 PM, Kääriäinen Anssi
wrote:
> This is probably a silly idea, but I have been wondering about the
> following idea: Instead of having visibility info in the row header,
> have a couple of row visibility slots in the page header. These slots
> could be shared between row
On Tue, Oct 11, 2011 at 4:00 PM, Florian Pflug wrote:
> On Oct11, 2011, at 21:27 , Robert Haas wrote:
>> Alternatively, we could try to graft the concept of a self-clustering
>> table on top of the existing heap implementation. But I'm having
>> trouble seeing how that would work. The TODO descr
Robert Haas writes:
> Alternatively, we could try to graft the concept of a self-clustering
> table on top of the existing heap implementation. But I'm having
> trouble seeing how that would work. The TODO describes it as
> something like "maintain CLUSTER ordering", but that's a gross
> oversim
Robert Haas wrote:
"""
And it seems to me that there could easily be format changes that
would make sense for particular cases, but not across the board,
like:
- index-organized tables (heap is a btree, and secondary indexes
reference the PK rather than the TID; this is how MySQL does it, and
Orac
On Oct11, 2011, at 21:27 , Robert Haas wrote:
> Alternatively, we could try to graft the concept of a self-clustering
> table on top of the existing heap implementation. But I'm having
> trouble seeing how that would work. The TODO describes it as
> something like "maintain CLUSTER ordering", but
On Tue, Oct 11, 2011 at 3:02 PM, Kevin Grittner
wrote:
> Robert Haas wrote:
>>> [implement "clustered index" as a covering index with all columns
>>> which are present in the heap]
>> I guess we could do that, but I'm not convinced there would be
>> much benefit.
>
> The "traditional" way to impl
Robert Haas wrote:
>> [implement "clustered index" as a covering index with all columns
>> which are present in the heap]
> I guess we could do that, but I'm not convinced there would be
> much benefit.
The "traditional" way to implement a clustered index is to have the
leaf level of the ind
On Tue, Oct 11, 2011 at 7:08 AM, Royce Ausburn wrote:
> I wonder, could the recent work on index only scans pave the way for auto
> clustered tables? Consider a wide, mostly insert table with some subset of
> columns that I'd like to cluster on. I'm after locality of tuples that are
> very fr
Hi all,
I wonder, could the recent work on index only scans pave the way for auto
clustered tables? Consider a wide, mostly insert table with some subset of
columns that I'd like to cluster on. I'm after locality of tuples that are
very frequently fetched together, but not keen on the downtim
