Re: "Truncated" tuples for tuple hash tables
От | Tom Lane |
---|---|
Тема | Re: "Truncated" tuples for tuple hash tables |
Дата | |
Msg-id | 22702.1151354590@sss.pgh.pa.us обсуждение исходный текст |
Ответ на | Re: "Truncated" tuples for tuple hash tables (Tom Lane <tgl@sss.pgh.pa.us>) |
Ответы |
Re: "Truncated" tuples for tuple hash tables
|
Список | pgsql-hackers |
I wrote: > There isn't any benefit except where we collect lots of tuples, which is > to say tuplesort/tuplestore/tuplehashtable. In other places in the > executor, there's basically only one transient tuple in existence per > plan node; jumping through hoops to save 16 bytes per plan node is just > silly. (What's more, as of 8.1 most of those tuples will be in "virtual > tuple" format anyway, and so the optimization wouldn't make any > difference at all...) After further study of the code, here's my hit-list of places that could make worthwhile use of MinimalTuples: tuplesort.c (in-memory, on-disk case done already)tuplestore.c (in-memory and on-disk)TupleHashTable (execGrouping.c ---used by nodeAgg and nodeSubplan)hash joins (in-memory hash table and tuple "batch" files)analyze.c (tuples collected in-memoryfor stats analysis) It looks like there is actually not anyplace else in the executor where we "materialize" tuples anymore, except for execMain.c's INSERT/UPDATE code, which of course is going to want full tuples it can stash on disk. Everything else is dealing in TupleTableSlots that probably contain virtual tuples. So in one sense this *is* "all across the executor". But the amount of code to touch seems pretty limited. regards, tom lane
В списке pgsql-hackers по дате отправления: