Skip site navigation (1) Skip section navigation (2)

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: (view raw, whole thread or download thread mbox)
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


pgsql-hackers by date

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

Privacy Policy | About PostgreSQL
Copyright © 1996-2017 The PostgreSQL Global Development Group