Re: Add primary key/unique constraint using prefix columns of an index

From: Simon Riggs <simon(at)2ndQuadrant(dot)com>
To: Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us>
Cc: Jeff Janes <jeff(dot)janes(at)gmail(dot)com>, pgsql-hackers <pgsql-hackers(at)postgresql(dot)org>
Subject: Re: Add primary key/unique constraint using prefix columns of an index
Date: 2012-05-22 21:36:38
Message-ID: CA+U5nMLegCLHfehp40+dKUk6Db++K-REKNVJsQSD5P97=g6u+Q@mail.gmail.com
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-hackers

On 22 May 2012 18:41, Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us> wrote:

> It'd be better to work on index-organized tables

My earlier analysis showed that IOTs are essentially the same thing as
block-level indexes, referred to as GITs by Heikki. (Robert referred
to these as Lossy Indexes recently, which was not the case - that
aspect was exactly the reason for rejection previously, so we should
not retread that path - indexes can operate at block level without
being lossy).

The number of index pointers is identical in each case, so IOTs are
not any more efficient in terms of space usage or I/O.

IOTs are much more difficult to implement, so I can't see any reason
to work on them. For example, having heap rows migrate on a block
split will cause havoc with our index implementation. We haven't
worked out how to re-join blocks that have split while maintaining
concurrency, so IOTs would require some pretty drastic repacking with
a severe lock type. Please lets avoid IOTs.

--
 Simon Riggs                   http://www.2ndQuadrant.com/
 PostgreSQL Development, 24x7 Support, Training & Services

In response to

Browse pgsql-hackers by date

  From Date Subject
Next Message Alexander Korotkov 2012-05-22 21:38:06 Re: Draft release notes complete
Previous Message Bruce Momjian 2012-05-22 21:27:47 Re: Draft release notes complete