Skip site navigation (1) Skip section navigation (2)

Re: A thought on Index Organized Tables

From: Greg Stark <gsstark(at)mit(dot)edu>
To: Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us>
Cc: Gokulakannan Somasundaram <gokul007(at)gmail(dot)com>, Karl Schnaitter <karlsch(at)gmail(dot)com>, pgsql-hackers list <pgsql-hackers(at)postgresql(dot)org>
Subject: Re: A thought on Index Organized Tables
Date: 2010-02-26 12:54:07
Message-ID: (view raw, whole thread or download thread mbox)
Lists: pgsql-hackers
On Fri, Feb 26, 2010 at 4:47 AM, Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us> wrote:
>> I feel the other one is easy. To store the hint bits inside the ItemId, in
>> the place of size.
> No, we're not going there.  That breaks the fundamental page content
> manipulation algorithms, and falls down for tuples not yet stored in a
> page (or being examined without a pointer to the page readily at hand),
> and has no redeeming social value anyway compared to doing it in the
> proven fashion.

Well we were already talking about moving the hint bits to someplace
else to enable CRC checking. My favourite place was the line pointer,
but you wanted a separate area -- either of which would have these

But this is all irrelevant to the particular issue at hand. The bigger
point is that you've chosen a change that requires massive changes to
all different parts of the system and causes problems for all
different situations. You might be able to come up with solutions for
some of them but I bet there are some you realize later are insoluble.
And a lot of the solutions themselves have problems or impose
limitations that we won't be able to live with.

Much better to take on a "simple" project like enabling full
sequential index scans which you claimed you had a solution for and
which is in any case an important sub-problem for IOT.


In response to


pgsql-hackers by date

Next:From: Gokulakannan SomasundaramDate: 2010-02-26 12:57:39
Subject: Re: A thought on Index Organized Tables
Previous:From: Rémi ZaraDate: 2010-02-26 12:47:26
Subject: Re: NaN/Inf fix for ECPG

Privacy Policy | About PostgreSQL
Copyright © 1996-2017 The PostgreSQL Global Development Group