From: | Leonardo F <m_lists(at)yahoo(dot)it> |
---|---|
To: | Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us> |
Cc: | Greg Stark <stark(at)mit(dot)edu>, pgsql-hackers(at)postgresql(dot)org |
Subject: | Re: About "Our CLUSTER implementation is pessimal" patch |
Date: | 2010-01-21 17:00:20 |
Message-ID: | 638245.69950.qm@web29020.mail.ird.yahoo.com |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-hackers |
> > I meant to add only ASC/DESC; I would leave all other cases
> > (non-btrees, custom expression btrees) to use the old index-scan method.
>
> That hardly seems acceptable.
Well I brought up that in an earlier post:
http://old.nabble.com/Re%3A-About-%22Our-CLUSTER-implementation-is-pessimal%22-patch-p27179107.html
I hoped that since people mostly (>95%?) use plain btree indexes,
a patch that helped CLUSTER with using such indexes would be fine
(at least at first...). I guess that a patch that deals with all other types of
indexes would be way more complicated (not at the "planning" stage,
but in the scan+sort phase)?
> I hardly think that keeping yourself at arm's length from the planner
> by getting cozy with SPI internals is a net improvement in modularity.
So you think that code snippet that I sent earlier (the function that uses
create_index_path etc) could be put in planner.c (almost) as it is? It looked
clumsy to me (I liked the SPI code better)
Leonardo
From | Date | Subject | |
---|---|---|---|
Next Message | Tom Lane | 2010-01-21 17:12:10 | Re: About "Our CLUSTER implementation is pessimal" patch |
Previous Message | Pavel Stehule | 2010-01-21 16:59:58 | Re: 8.5 vs. 9.0, Postgres vs. PostgreSQL |