Re: Yet another abort-early plan disaster on 9.3
| От | Claudio Freire |
|---|---|
| Тема | Re: Yet another abort-early plan disaster on 9.3 |
| Дата | |
| Msg-id | CAGTBQpb=hrq1pYDDBZBiUrMiO7vna2WDhwpPiYd1OW5eA8gdhg@mail.gmail.com обсуждение исходный текст |
| Ответ на | Re: Yet another abort-early plan disaster on 9.3 (Greg Stark <stark@mit.edu>) |
| Список | pgsql-performance |
On Sat, Sep 20, 2014 at 3:38 AM, Greg Stark <stark@mit.edu> wrote: >> > Is there a canonical case of where 'abort early' plans help? (I'm new >> > to that term -- is it a recent planner innovation...got any handy >> > links?) >> >> Yeah, here's an example of the canonical case: >> >> Table t1 ( a, b, c ) >> >> - "b" is low-cardinality >> - "c" is high-cardinality >> - There are separate indexes on both b and c. >> >> SELECT a, b, c FROM t1 >> WHERE b = 2 >> ORDER BY c LIMIT 1; > > You badly want a partial index on c WHERE b=2 for each value of 2 which > appears in your queries. > > It would be neat to have an opclass which worked like that. Which would > amount to having prefix compression perhaps. I've been looking at that exactly. One complexity of it, is that splitting becomes much harder. As in, recursive.
В списке pgsql-performance по дате отправления: