From: | Leonardo F <m_lists(at)yahoo(dot)it> |
---|---|
To: | Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us> |
Cc: | pgsql-hackers(at)postgresql(dot)org |
Subject: | Re: About "Our CLUSTER implementation is pessimal" patch |
Date: | 2010-01-26 16:56:38 |
Message-ID: | 823922.75611.qm@web29014.mail.ird.yahoo.com |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-hackers |
> If we ever get another index type that supports ordered
> scans, it'll be time enough to worry about cases like this.
Ok
> BTW, I think you could use tuplesort_begin_index_btree() rather than
> touching _bt_mkscankey_nodata directly.
well I created my own tuplesort_begin_rawheap method (copied from:
http://archives.postgresql.org/pgsql-hackers/2008-08/msg01371.php ).
From there I call _bt_mkscankey_nodata (as tuplesort_begin_index_btree()
does), plus I set up everything else I'm going to need in tuplesort.
Another question:
why is IndexInfo.ii_Expressions a list? How can an index have more than
one expression? Sorry if it's a stupid question, but I'm not familiar with
index expressions.
I think I'm almost there (some very stupid tests pass). I'll try to submit a
patch soon to understand if I'm going in the right direction.
Leonardo
From | Date | Subject | |
---|---|---|---|
Next Message | Erik Rijkers | 2010-01-26 17:19:17 | testing cvs HEAD - HS/SR - missing file |
Previous Message | Kevin Grittner | 2010-01-26 16:15:36 | Re: Review: listagg aggregate |