Re: POC: Lock updated tuples in tuple_update() and tuple_delete()

Поиск
Список
Период
Сортировка
От Chris Travers
Тема Re: POC: Lock updated tuples in tuple_update() and tuple_delete()
Дата
Msg-id 167846860062.628976.2440696515718158538.pgcf@coridan.postgresql.org
обсуждение исходный текст
Ответ на Re: POC: Lock updated tuples in tuple_update() and tuple_delete()  (Alexander Korotkov <aekorotkov@gmail.com>)
Ответы Re: POC: Lock updated tuples in tuple_update() and tuple_delete()  (Alexander Korotkov <aekorotkov@gmail.com>)
Список pgsql-hackers
"Right, the improvement this patch gives to the heap is not the full motivation. Another motivation is the improvement
itgives to TableAM API. Our current API implies that the effort on locating the tuple by tid is small. This is more or
lesstrue for the heap, where we just need to pin and lock the buffer. But imagine other TableAM implementations, where
locatinga tuple is more expensive."
 

Yeah. Our TableAM API is a very nice start to getting pluggable storage, but we still have a long ways to go to have an
abilityto really provide a wide variety of pluggable storage engines.
 

In particular, the following approaches are likely to have much more expensive tid lookups:
 - columnar storage (may require a lot of random IO to reconstruct a tuple)
 - index oriented storage (tid no longer physically locatable in the file via seek)
 - compressed cold storage like pg_ctyogen (again seek may be problematic).

To my mind I think the performance benefits are a nice side benefit, but the main interest I have on this is regarding
improvementsin the TableAM capabilities.  I cannot see how to do this without a lot more infrastructure. 

В списке pgsql-hackers по дате отправления:

Предыдущее
От: Tom Lane
Дата:
Сообщение: Re: RLS makes COPY TO process child tables
Следующее
От: Tom Lane
Дата:
Сообщение: Re: pg_usleep for multisecond delays