"Joshua D. Drake" <jd@commandprompt.com> writes:
> Just to throw my two bits in here :). If we do that, how does that
> effect the idea that most people in the web world use (id serial primary
> key), even though that is not what they are searching on?
"affect". But I think you're right that generally you'll have two indexes.
> More specifically, does HOT help conditions where a composite comes into
> play (session_id,last_active) ... which would be a more heavily updated
> index than just the primary key.
Well if you're indexing a column that you're updating then you've already
failed your saving throw.
The case we're trying to deal with is when you're updating columns that
*aren't* indexed and therefore really don't need redundant index pointers for
each tuple version with identical to the old versions. Especially since those
index pointers are what's preventing us from vacuuming the old tuple versions.
If you are updating an index key then there's no question you're going to need
vacuum to clean out your index.
-- Gregory Stark EnterpriseDB http://www.enterprisedb.com