Heikki Linnakangas wrote:
> Tom Lane wrote:
>> What if we only applied
>> HOT to primary-key indexes, so that there was certainly not more than
>> one index per table that the property applies to?
> The main objective of HOT is to enable retail vacuum of HOT-updated
> tuples. Doing the above would make it useless for that purpose,
> at least when there's more than one index on the table. Granted,
> there's a lot of tables with just one index out there, but it's a
> big limitation nevertheless.


> An extension of that idea, though is to store a flag per index in
> the HOT-updated tuple. We would then need a mapping between 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.



EnterpriseDB        http://www.enterprisedb.com

---------------------------(end of broadcast)---------------------------
TIP 7: You can help support the PostgreSQL project by donating at


Reply via email to