Re: Question: pg_class attributes and race conditions ?

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

In response to

Responses

Browse pgsql-hackers by date

  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 ?