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

Re: About "Our CLUSTER implementation is pessimal" patch

From: Leonardo F <m_lists(at)yahoo(dot)it>
To: Heikki Linnakangas <heikki(dot)linnakangas(at)enterprisedb(dot)com>
Cc: pgsql-hackers(at)postgresql(dot)org, stark(at)enterprisedb(dot)com
Subject: Re: About "Our CLUSTER implementation is pessimal" patch
Date: 2010-01-15 15:48:29
Message-ID: 907930.87593.qm@web29012.mail.ird.yahoo.com (view raw or flat)
Thread:
Lists: pgsql-hackers
> Yeah, I think you could do that, I agree it feels better that way.
> You'll still need new copytup and comparetup functions, though, to deal
> with HeapTupleHeaders instead of MinimalTuples, or modify the existing
> ones to handle both. 

You meant HeapTuple, not HeapTupleHeaders, right?

Mmh, didn't think of those two functions; I might as well start with Gregory
Stark's patch (that is: using HeapTuple)

> And some way to indicate that you want to preserve
> the visibility information when you create the tuplesort, maybe a new
> parameter to tuplesort_begin_heap().

I guess that using Gregory Stark's patch there's no need for it, since it uses
HeapTuples, right?

A patch that:

1) uses always the old CLUSTER method for non-btree indexes and for
expression indexes
2) add a whole set of new functions to tuplesort (as in Gregory Stark's patch)

would be rejected "for sure"? Or can be thought as a "better than nothing,
works in 90% cases" patch?


Leonardo


      

In response to

Responses

pgsql-hackers by date

Next:From: Greg StarkDate: 2010-01-15 16:01:25
Subject: Re: New XLOG record indicating WAL-skipping
Previous:From: Kevin GrittnerDate: 2010-01-15 15:47:28
Subject: Re: Testing with concurrent sessions

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