From: | Gregory Stark <stark(at)enterprisedb(dot)com> |
---|---|
To: | "Joshua D(dot) Drake" <jd(at)commandprompt(dot)com> |
Cc: | "Tom Lane" <tgl(at)sss(dot)pgh(dot)pa(dot)us>, "Pavan Deolasee" <pavan(dot)deolasee(at)enterprisedb(dot)com>, <pgsql-hackers(at)postgresql(dot)org> |
Subject: | Re: Question: pg_class attributes and race conditions ? |
Date: | 2007-03-16 18:05:03 |
Message-ID: | 87abydkqsw.fsf@stark.xeocode.com |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-hackers |
"Joshua D. Drake" <jd(at)commandprompt(dot)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
From | Date | Subject | |
---|---|---|---|
Next Message | William Garrison | 2007-03-16 18:09:17 | Bug in CREATE/DROP TABLESPACE command |
Previous Message | Simon Riggs | 2007-03-16 17:44:45 | Re: Question: pg_class attributes and race conditions ? |