Re: Question: pg_class attributes and race conditions ?
| От | Pavan Deolasee | 
|---|---|
| Тема | Re: Question: pg_class attributes and race conditions ? | 
| Дата | |
| Msg-id | 45FAD412.30103@enterprisedb.com обсуждение исходный текст  | 
		
| Ответ на | Re: Question: pg_class attributes and race conditions ? (Tom Lane <tgl@sss.pgh.pa.us>) | 
| Список | pgsql-hackers | 
Tom Lane wrote:> "Pavan Deolasee" <pavan.deolasee@enterprisedb.com> writes:>> Any thoughts on the overall approach ?>> Fragileand 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 tolook 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 thatthe 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
В списке pgsql-hackers по дате отправления: