From: | "Pavan Deolasee" <pavan(dot)deolasee(at)enterprisedb(dot)com> |
---|---|
To: | "Tom Lane" <tgl(at)sss(dot)pgh(dot)pa(dot)us> |
Cc: | <pgsql-hackers(at)postgresql(dot)org> |
Subject: | Re: Question: pg_class attributes and race conditions ? |
Date: | 2007-03-16 17:29:54 |
Message-ID: | 45FAD412.30103@enterprisedb.com |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-hackers |
Tom Lane wrote:
> "Pavan Deolasee" <pavan(dot)deolasee(at)enterprisedb(dot)com> writes:
>> Any thoughts on the overall approach ?
>
> Fragile and full of race conditions :-(.
>
Yes, it looks a bit complex. But IMHO we can get around that.
Do you have any ideas in mind about doing that ?
> I thought from the beginning
> that CREATE INDEX might be a showstopper for the whole HOT concept,
> and it's starting to look like that's the case.
I remember you raised this concern very early, but I am hopeful
that we would be able to solve this. Would it be acceptable
to have a simple (though not the best) solution for this release
and then improve later on ? As I mentioned earlier, one option
is to CHILL the table, if required, holding AccessExclusive lock,
just like VACUUM FULL. I am assuming here that CREATE INDEX is
not such a common activity, isn't that true ?
> I think what we need to get away from is the assumption that HOT-ness
> for one index is the same as HOT-ness for all. 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?
>
I think that will take away the ability to reuse HEAP_ONLY tuples
without vacuuming the heap and index.
Thanks,
Pavan
--
EnterpriseDB http://www.enterprisedb.com
From | Date | Subject | |
---|---|---|---|
Next Message | Simon Riggs | 2007-03-16 17:44:45 | Re: Question: pg_class attributes and race conditions ? |
Previous Message | Heikki Linnakangas | 2007-03-16 17:22:03 | Re: Question: pg_class attributes and race conditions ? |