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 ---------------------------(end of broadcast)--------------------------- TIP 9: In versions below 8.0, the planner will ignore your desire to choose an index scan if your joining column's datatypes do not match
