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  (Tom Lane <tgl@sss.pgh.pa.us>)
Список 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 по дате отправления:

Предыдущее
От: Alvaro Herrera
Дата:
Сообщение: Re: [PATCHES] Non-transactional pg_class, try 2
Следующее
От: Greg Stark
Дата:
Сообщение: Re: Inheritance, CREATE TABLE LIKE, and partitioned tables