From: | "Simon Riggs" <simon(at)2ndquadrant(dot)com> |
---|---|
To: | "Heikki Linnakangas" <heikki(at)enterprisedb(dot)com> |
Cc: | "Pavan Deolasee" <pavan(dot)deolasee(at)enterprisedb(dot)com>, "Tom Lane" <tgl(at)sss(dot)pgh(dot)pa(dot)us>, <pgsql-hackers(at)postgresql(dot)org> |
Subject: | Re: CREATE INDEX and HOT (was Question: pg_classattributes and race conditions ?) |
Date: | 2007-03-19 12:05:19 |
Message-ID: | 1174305919.4160.718.camel@silverbirch.site |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-hackers |
On Mon, 2007-03-19 at 10:51 +0000, Heikki Linnakangas wrote:
> Pavan Deolasee wrote:
> > Heikki Linnakangas wrote:
> > > Pavan Deolasee wrote:
> > > We would only need the extra byte in HOT-updated tuples.
> > Alternatively, we could use the bits we have free in infomask2. There's
> > currently 5 bits free, using just 2 or 3 of those would get us quite
> > far. Or just one, which would be the Tom's suggestion of only using HOT
> > for tables with a single index.
> > >
> >
> > We've already used three of those, two for tracking HEAP_ONLY
> > and HOT_UPDATED tuples and one for tracking fragmented tuple.
>
> HEAP_ONLY_TUPLE would go away in favor of the per-index bits. So we have
> bits available for three indexes.
ISTM that we are getting very close to a great idea here.
I was unwilling to compromise to have HOT if only one index existed, but
IMHO allowing HOT with <= 3 indexes is an acceptable compromise for this
release. (We can always use vertical partitioning techniques to allow
additional access paths to be added to the same table - I'd be very
happy to document that with worked examples, if requried).
I trust that we will think of ways of extending that limit in later
releases.
--
Simon Riggs
EnterpriseDB http://www.enterprisedb.com
From | Date | Subject | |
---|---|---|---|
Next Message | Heikki Linnakangas | 2007-03-19 12:23:01 | Indexam interface proposal |
Previous Message | Simon Riggs | 2007-03-19 11:21:43 | Re: CREATE INDEX and HOT (was Question:pg_classattributes and race conditions ?) |