On Fri, Mar 10, 2023 at 8:17 PM Chris Travers <chris.travers@gmail.com> wrote:
> "Right, the improvement this patch gives to the heap is not the full motivation. Another motivation is the
improvementit gives to TableAM API. Our current API implies that the effort on locating the tuple by tid is small. This
ismore or less true for the heap, where we just need to pin and lock the buffer. But imagine other TableAM
implementations,where locating a 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
anability to 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
regardingimprovements in the TableAM capabilities. I cannot see how to do this without a lot more infrastructure.
Chris, thank you for your feedback.
The revised patch set is attached. Some comments are improved. Also,
we implicitly skip the new facility for the MERGE case. As I get Dean
Rasheed is going to revise the locking for MERGE soon [1].
Pavel, could you please re-run your test case on the revised patch?
1. https://www.postgresql.org/message-id/CAEZATCU9e9Ccbi70yNbCcF7xvZ+zrjiD0_6eEq2zEZA1p+707A@mail.gmail.com
------
Regards,
Alexander Korotkov
