Heikki Linnakangas wrote:> Tom Lane wrote:>> What if we only applied>> HOT to primary-key indexes, so that there was
certainlynot more than>> one index per table that the property applies to?>> The main objective of HOT is to enable
retailvacuum of HOT-updated> tuples. Doing the above would make it useless for that purpose,> at least when there's
morethan one index on the table. Granted,> there's a lot of tables with just one index out there, but it's a> big
limitationnevertheless.>
Agree.
> An extension of that idea, though is to store a flag per index in> the HOT-updated tuple. We would then need a
mappingbetween bits in> the tuple header to indexes, for example as a new column in pg_index.>
I like the idea. The major objection would be that it adds a byte
to the tuple header which when considered along with the null
bitmap, may actually make the header 8 bytes larger in the
worst case.
Also, I am also worried about the additional complexity introduced
with this. We can and should work on this idea, I am wondering
whether it would be too much to do before the feature freeze.
I am personally inclined towards doing something simpler to
tackle the CREATE INDEX issue at the moment. But if that is not
acceptable and/or you or anyone else is willing help me on this,
we can work on a better solution.
Thanks,
Pavan
--
EnterpriseDB http://www.enterprisedb.com
