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

Peripheral Links

Header And Logo

PostgreSQL
| The world's most advanced open source database.

Site Navigation

Search for
  Advanced Search

Re: "Truncated" tuples for tuple hash tables


  • From: Simon Riggs <simon(at)2ndquadrant(dot)com>
  • To: Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us>
  • Cc: Martijn van Oosterhout <kleptog(at)svana(dot)org>, pgsql-hackers(at)postgresql(dot)org
  • Subject: Re: "Truncated" tuples for tuple hash tables
  • Date: Mon, 26 Jun 2006 21:59:07 +0100
  • Message-id: <1151355547(dot)2479(dot)105(dot)camel(at)localhost(dot)localdomain>

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




Home | Main Index | Thread Index

Privacy Policy | PostgreSQL Archives hosted by Command Prompt, Inc. | Designed by tinysofa
Copyright © 1996 – 2008 PostgreSQL Global Development Group