Re: "Truncated" tuples for tuple hash tables

From: Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us>
To: Simon Riggs <simon(at)2ndquadrant(dot)com>
Cc: Martijn van Oosterhout <kleptog(at)svana(dot)org>, pgsql-hackers(at)postgresql(dot)org
Subject: Re: "Truncated" tuples for tuple hash tables
Date: 2006-06-26 20:43:10
Message-ID: 22702.1151354590@sss.pgh.pa.us
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: 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-memory for 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

In response to

Responses

Browse pgsql-hackers by date

  From Date Subject
Next Message Tom Lane 2006-06-26 20:49:58 Re: [COMMITTERS] pgsql: Change the row constructor syntax (ROW(...))
Previous Message elein 2006-06-26 20:27:03 Re: Inheritance, CREATE TABLE LIKE, and partitioned tables