Re: About "Our CLUSTER implementation is pessimal" patch
От | Leonardo F |
---|---|
Тема | Re: About "Our CLUSTER implementation is pessimal" patch |
Дата | |
Msg-id | 907930.87593.qm@web29012.mail.ird.yahoo.com обсуждение исходный текст |
Ответ на | Re: About "Our CLUSTER implementation is pessimal" patch (Heikki Linnakangas <heikki.linnakangas@enterprisedb.com>) |
Ответы |
Re: About "Our CLUSTER implementation is pessimal" patch
|
Список | 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
В списке pgsql-hackers по дате отправления: