Ühel kenal päeval, E, 2007-03-19 kell 12:05, kirjutas Simon Riggs:
> 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.
But you probably have to do some kind of SUPERFULL VACUUM if you want to
DROP and CREATE the third index. You will probably have to touch all
tuples, regardless of weather they are live or not, or if will be moved
or not, just to kclean ot bits for the just-deleted index.
Maybe a CLUSTER would be an answer here.
> 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).
Maybe using more than one TOAST table as means of vertical
partitioning ?
> I trust that we will think of ways of extending that limit in later
> releases.
>
--
----------------
Hannu Krosing
Database Architect
Skype Technologies OÜ
Akadeemia tee 21 F, Tallinn, 12618, Estonia
Skype me: callto:hkrosing
Get Skype for free: http://www.skype.com
