Re: MDAM techniques and Index Skip Scan patch
От | Andres Freund |
---|---|
Тема | Re: MDAM techniques and Index Skip Scan patch |
Дата | |
Msg-id | 20220322230614.mn3u62zpz5fqeetm@alap3.anarazel.de обсуждение исходный текст |
Ответ на | Re: MDAM techniques and Index Skip Scan patch (Tom Lane <tgl@sss.pgh.pa.us>) |
Ответы |
Re: MDAM techniques and Index Skip Scan patch
Re: MDAM techniques and Index Skip Scan patch |
Список | pgsql-hackers |
Hi, On 2022-03-22 16:55:49 -0400, Tom Lane wrote: > 4. I find each of the above ideas to be far more attractive than > optimizing SELECT-DISTINCT-that-matches-an-index, so I don't really > understand why the current patchsets seem to be driven largely > by that single use-case. It's something causing plenty pain in production environments... Obviously it'd be even better if the optimization also triggered in cases like SELECT some_indexed_col FROM blarg GROUP BY some_indexed_col which seems to be what ORMs like to generate. > BTW, I've had a bee in my bonnet for a long time about whether some of > nbtree's scan setup work could be done once during planning, rather than > over again during each indexscan start. It does show up in simple-index-lookup heavy workloads. Not as a major thing, but it's there. And it's just architecturally displeasing :) Are you thinking of just moving the setup stuff in nbtree (presumably parts of _bt_first() / _bt_preprocess_keys()) or also stuff in ExecIndexBuildScanKeys()? The latter does show up a bit more heavily in profiles than nbtree specific setup, and given that it's generic executor type stuff, seems even more amenable to being moved to plan time. Greetings, Andres Freund
В списке pgsql-hackers по дате отправления: