Re: About "Our CLUSTER implementation is pessimal" patch

> 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

Leonardo F <m_lists(at)yahoo(dot)it> writes:
>> Rule it out. Note you should be looking at pg_am.amcanorder, not
>> hardwiring knowledge of particular index types.

> 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.

Well, actually, it's not *quite* as btree specific as all that. Note
the fine print in section 50.3:

: Some access methods return index entries in a well-defined order,
: others do not. If entries are returned in sorted order, the access
: method should set pg_am.amcanorder true to indicate that it supports
: ordered scans. All such access methods must use btree-compatible
: strategy numbers for their equality and ordering operators.

So in principle you could probably do something that avoided any
"official" dependency on btree. Whether it's worth doing in practice is
pretty dubious though. I agree that calling a routine that claims to be
btree-specific would be best done only after making a specific test for
BTREE_AM_OID. If we ever get another index type that supports ordered
scans, it'll be time enough to worry about cases like this.

BTW, I think you could use tuplesort_begin_index_btree() rather than
touching _bt_mkscankey_nodata directly. Doesn't affect the fundamental
problem, but you might as well use the most convenient API.

regards, tom lane

> 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

Leonardo F wrote:
> 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.

Consider multi-column indexes, ie:

CREATE INDEX i_foo ON foo (length(a), length(b));

Maybe you're confusing expression indexes with partial indexes? The
predicate for a partial index is stored in ii_Predicate, not
ii_Expressions. Although ii_Predicate is a list too; in that case it's a
list of clauses that are implicitly ANDed together.

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

> Consider multi-column indexes, ie:
> CREATE INDEX i_foo ON foo (length(a), length(b));

Ok, I've never thought of expression indexes that way
(in the (expr1,expr2,exprN) form): that is a good example.

> Maybe you're confusing expression indexes with partial indexes?

No no, that was exactly what I needed to know.

Thank you very much

Leonardo