Re: "Truncated" tuples for tuple hash tables
От | Simon Riggs |
---|---|
Тема | Re: "Truncated" tuples for tuple hash tables |
Дата | |
Msg-id | 1151355547.2479.105.camel@localhost.localdomain обсуждение исходный текст |
Ответ на | Re: "Truncated" tuples for tuple hash tables (Tom Lane <tgl@sss.pgh.pa.us>) |
Ответы |
Re: "Truncated" tuples for tuple hash tables
|
Список | pgsql-hackers |
On Mon, 2006-06-26 at 16:43 -0400, Tom Lane wrote: > 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) Thats the list I thought you meant. > analyze.c (tuples collected in-memory for stats analysis) Do we save enough there for us to care? Will that allow us to increase the sample size for larger tables? -- Simon Riggs EnterpriseDB http://www.enterprisedb.com
В списке pgsql-hackers по дате отправления: