Re: About "Our CLUSTER implementation is pessimal" patch
От | Leonardo F |
---|---|
Тема | Re: About "Our CLUSTER implementation is pessimal" patch |
Дата | |
Msg-id | 638245.69950.qm@web29020.mail.ird.yahoo.com обсуждение исходный текст |
Ответ на | Re: About "Our CLUSTER implementation is pessimal" patch (Tom Lane <tgl@sss.pgh.pa.us>) |
Ответы |
Re: About "Our CLUSTER implementation is pessimal" patch
|
Список | 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
В списке pgsql-hackers по дате отправления: