Prev: [HACKERS] Why doesn't smgr_redo truncate the VM fork too?
Next: [HACKERS] Some belated patch review for "Buffers" explain analyze patch
From: Josh Kupershmidt on 9 Feb 2010 11:16
On Tue, Feb 9, 2010 at 5:49 AM, Leonardo F <m_lists(a)yahoo.it> wrote:

> Not even a comment? As I said, performance results on my system
> were very good....
>

Hi Leonardo,
Perhaps you could supply a .sql file containing a testcase illustrating the
performance benefits you tested with your patch -- as I understand, the sole
purpose of this patch is to speed up CLUSTER -- along with your results? The
existing src/test/regress/sql/cluster.sql looks like it only has some basic
sanity checks in it, and not performance tests. An idea of what hardware
you're testing on and any tweaks to postgresql.conf might be useful as well.

I was able to apply your patch cleanly and run CLUSTER with it, and "make
check" passed for me on OS X as well.

Hope this helps, and sorry I'm not able to offer more technical advice on
your patch.
Josh
From: Heikki Linnakangas on 10 Feb 2010 07:48
Leonardo F wrote:
> static void
> writetup_rawheap(Tuplesortstate *state, int tapenum, SortTuple *stup)
> {
> HeapTuple tuple = (HeapTuple) stup->tuple;

I think you're confusing HeapTuple and HeapTupleHeader. SortTuple->tuple
field should point to a HeapTupleHeader, not a HeapTuple.

The right mental model is that HeapTupleHeader is a physical tuple, one
that you store on disk for example. A HeapTuple is an in-memory wrapper,
or pointer if you will, to a HeapTupleHeader, and holds some additional
information on the tuple that's useful when operating on it.

To add to the confusion, MinimalTuple is a shortened counterpart of
HeapTuple*Header*, not HeapTuple. And SortTuple is an in-memory wrapper
similar to HeapTuple, containing additional information on the tuple
that helps with sorting.

I didn't look at the rest of the code in detail, but I think that's
where your problems are stemming from.

--
Heikki Linnakangas
EnterpriseDB http://www.enterprisedb.com

--
Sent via pgsql-hackers mailing list (pgsql-hackers(a)postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-hackers

 | 
Pages: 1
Prev: [HACKERS] Why doesn't smgr_redo truncate the VM fork too?
Next: [HACKERS] Some belated patch review for "Buffers" explain analyze patch