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. >
Agree. > 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. Thanks, Pavan -- EnterpriseDB http://www.enterprisedb.com ---------------------------(end of broadcast)--------------------------- TIP 7: You can help support the PostgreSQL project by donating at http://www.postgresql.org/about/donate
