Re: About "Our CLUSTER implementation is pessimal" patch - Mailing list pgsql-hackers

From Leonardo F
Subject Re: About "Our CLUSTER implementation is pessimal" patch
Date
Msg-id 221678.73628.qm@web29007.mail.ird.yahoo.com
Whole thread Raw
In response to About "Our CLUSTER implementation is pessimal" patch  (Leonardo F <m_lists@yahoo.it>)
Responses Re: About "Our CLUSTER implementation is pessimal" patch
List pgsql-hackers
> Rule it out.  Note you should be looking at pg_am.amcanorder, not
> hardwiring knowledge of particular index types.

Sorry, I replied "ok" too fast...


I can look at pg_am.amcanorder, but I would still need the ScanKey to be used

by tuplesort; and I can't find any other way of doing it than calling
_bt_mkscankey_nodata, which is btree-specific.

I guess either:

- add another function to the list of "Index Access Method Functions", something
that returns the ScanKey in case pg_am.amcanorder is true

or

- hardwiring the fact that the only way to seq scan + sort in CLUSTER is using
a btree... hence the call to _bt_mkscankey_nodata

But maybe there's another way of doing it, I don't know the code enough


Leonardo





pgsql-hackers by date:

Previous
From: Heikki Linnakangas
Date:
Subject: Re: Re: pgsql: In HS, Startup process sets SIGALRM when waiting for buffer pin.
Next
From: Simon Riggs
Date:
Subject: Re: Re: pgsql: In HS, Startup process sets SIGALRM when waiting for buffer pin.