Re: Pluggable Storage - Andres's take
Haribabu Kommi <kommi.haribabu@gmail.com>
On Mon, Jul 16, 2018 at 11:35 PM Andres Freund <andres@anarazel.de> wrote: > On 2018-07-04 20:11:21 +1000, Haribabu Kommi wrote: > > On Tue, Jul 3, 2018 at 5:06 PM Andres Freund <andres@anarazel.de> wrote: > > > > The most fundamental issues I had with Haribabu's last version from [2] > > > are the following: > > > > > > - The use of TableTuple, a typedef from void *, is bad from multiple > > > fronts. For one it reduces just about all type safety. There were > > > numerous bugs in the patch where things were just cast from HeapTuple > > > to TableTuple to HeapTuple (and even to TupleTableSlot). I think > it's > > > a really, really bad idea to introduce a vague type like this for > > > development purposes alone, it makes it way too hard to refactor - > > > essentially throwing the biggest benefit of type safe languages out > of > > > the window. > > > > > > > My earlier intention was to remove the HeapTuple usage entirely and > replace > > it with slot everywhere outside the tableam. But it ended up with > TableTuple > > before it reach to the stage because of heavy use of HeapTuple. > > I don't think that's necessary - a lot of the system catalog accesses > are going to continue to be heap tuple accesses. And the conversions you > did significantly continue to access TableTuples as heap tuples - it was > just that the compiler didn't warn about it anymore. > > A prime example of that is the way the rewriteheap / cluster > integreation was done. Cluster continued to sort tuples as heap tuples - > even though that's likely incompatible with other tuple formats which > need different state. > OK. Understood. > > > - the heap tableam did a heap_copytuple() nearly everywhere. Leading to > > > a higher memory usage, because the resulting tuples weren't freed or > > > anything. There might be a reason for doing such a change - we've > > > certainly discussed that before - but I'm *vehemently* against doing > > > that at the same time we introduce pluggable storage. Analyzing the > > > performance effects will be hard enough without changes like this. > > > > > > > How about using of slot instead of tuple and reusing of it? I don't know > > yet whether it is possible everywhere. > > Not quite sure what you mean? > I thought of using slot everywhere can reduce the use of heap_copytuple, I understand that you already did those changes from you reply from the other mail. > > Tasks / Questions: > > > > > > - split up patch > > > > > > > How about generating refactoring changes as patches first based on > > the code in your repo as discussed here[1]? > > Sure - it was just at the moment too much work ;) > Yes, it is too much work. How about doing this once most of the open items are finished? > > > > - Change heap table AM to not allocate handler function for each table, > > > instead allocate it statically. Avoids a significant amount of data > > > duplication, and allows for a few more compiler optimizations. > > > > > > > Some kind of static variable handlers for each tableam, but need to check > > how can we access that static handler from the relation. > > I'm not sure what you mean by "how can we access"? We can just return a > pointer from the constant data from the current handler? Except that > adding a bunch of consts would be good, the external interface wouldn't > need to change? > I mean we may need to store some tableam ID in each table, so that based on that ID we get the static tableam handler, because at a time there may be tables from different tableam methods. > > > > - change scan level slot creation to use tableam function for doing so > > > - get rid of slot->tts_tid, tts_tupleOid and potentially tts_tableOid > > > > > > > so with this there shouldn't be a way from slot to tid mapping or there > > should be some other way. > > I'm not sure I follow? > Replacing of heaptuple with slot, currently with slot only the tid is passed to the tableam methods, To get rid of the tid from slot, we may need any other method of passing? > > - bitmap index scans probably need a new tableam.h callback, abstracting > > > bitgetpage() > > > > > > > OK. > > Any chance you could try to tackle this? I'm going to be mostly out > this week, so we'd probably not run across each others feet... > OK, I will take care of the above point. Regards, Haribabu Kommi Fujitsu Australia
Commits
-
Add default_table_access_method to postgresql.conf.sample.
- 3a5c08aa0267 12.0 landed
- f7db0ac7d5b6 13.0 landed
-
tableam: Avoid relying on relation size to determine validity of tids.
- 147e3722f7e5 12.0 landed
-
tableam: Don't assume that every AM uses md.c style storage.
- 7f44ede59414 12.0 landed
-
Allow pg_class xid & multixid horizons to not be set.
- fdc7efcc30b1 12.0 landed
-
Fix slot type issue for fuzzy distance index scan over out-of-core table AM.
- b8b94ea129ff 12.0 cited
-
tableam: comment and formatting fixes.
- 6421011ea24d 12.0 landed
-
table: docs: fix typos and grammar.
- 86cc06d1cf9c 12.0 landed
-
tableam: basic documentation.
- b73c3a11963c 12.0 landed
-
Only allow heap in a number of contrib modules.
- 4b82664156c2 12.0 landed
-
tableam: Add table_finish_bulk_insert().
- d45e40158623 12.0 landed
-
tableam: sample scan.
- 73c954d24896 12.0 landed
-
tableam: bitmap table scan.
- bfbcad478f05 12.0 landed
-
tableam: Move heap specific logic from estimate_rel_size below tableam.
- 696d78469f37 12.0 landed
-
tableam: VACUUM and ANALYZE support.
- 737a292b5de2 12.0 landed
-
tableam: relation creation, VACUUM FULL/CLUSTER, SET TABLESPACE.
- d25f519107bf 12.0 landed
-
tableam: Support for an index build's initial table scan(s).
- 2a96909a4a8c 12.0 landed
-
tableam: Add table_get_latest_tid, to wrap heap_get_latest_tid.
- 2e3da03e9ee4 12.0 landed
-
tableam: Add helper for indexes to check if a corresponding table tuples exist.
- 71bdc99d0d7c 12.0 landed
-
tableam: Add and use table_fetch_row_version().
- 9a8ee1dc650b 12.0 landed
-
tableam: Use in CREATE TABLE AS and CREATE MATERIALIZED VIEW.
- 919e48b94301 12.0 landed
-
Ensure sufficient alignment for ParallelTableScanDescData in BTShared.
- 8cacea7a7251 12.0 landed
-
Don't reuse slots between root and partition in ON CONFLICT ... UPDATE.
- 277cb789836b 12.0 landed
-
Use a virtual rather than a heap slot in two places where that suffices.
- 70b9bda65f81 12.0 landed
-
Store tuples for EvalPlanQual in slots, rather than as HeapTuples.
- ad0bda5d24ea 12.0 landed
-
Use slots in trigger infrastructure, except for the actual invocation.
- ff11e7f4b9ae 12.0 landed
-
Store table oid and tuple's tid in tuple slots directly.
- b8d71745eac0 12.0 landed
-
Allow to use HeapTupleData embedded in [Buffer]HeapTupleTableSlot.
- 5408e233f066 12.0 landed
-
Add ExecStorePinnedBufferHeapTuple.
- 8aa02b52db11 12.0 landed
-
Add ArchiveOpts to pass options to ArchiveEntry
- f831d4accda0 12.0 cited
-
Rename RelationData.rd_amroutine to rd_indam.
- 346ed70b0ad7 12.0 landed
-
Rephrase references to "time qualification".
- ebcc7bf949ba 12.0 landed
-
Move remaining code from tqual.[ch] to heapam.h / heapam_visibility.c.
- c91560defc57 12.0 landed
-
Move generic snapshot related code from tqual.h to snapmgr.h.
- b7eda3e0e334 12.0 landed
-
Remove superfluous tqual.h includes.
- e7cc78ad43eb 12.0 landed
-
Don't duplicate parallel seqscan shmem sizing logic in nbtree.
- 90525d7b4e0f 12.0 landed
-
Move vacuumlazy.c into access/heap.
- 285d8e12055f 12.0 landed
-
Support parallel bitmap heap scans.
- f35742ccb7aa 10.0 cited