Re: Generating partitioning tuple conversion maps faster
От | David Rowley |
---|---|
Тема | Re: Generating partitioning tuple conversion maps faster |
Дата | |
Msg-id | CAKJS1f_D3SK4UJMdFCSbgP-wciMCVUiWM=7gXs=_Z6OL6fjtsg@mail.gmail.com обсуждение исходный текст |
Ответ на | Re: Generating partitioning tuple conversion maps faster (Alexander Kuzmenkov <a.kuzmenkov@postgrespro.ru>) |
Ответы |
Re: Generating partitioning tuple conversion maps faster
|
Список | pgsql-hackers |
On 30 June 2018 at 00:22, Alexander Kuzmenkov <a.kuzmenkov@postgrespro.ru> wrote: > On 06/29/2018 03:25 AM, David Rowley wrote: >> I've attached a patch that uses SearchSysCacheAttName to speed up >> these translations in the planner. > > Good idea. On my desktop, this gives 270 tps dropped vs 610 tps plain (for > updates). If you combine it with persistent inner loop index, it's probably > going to be even faster, because it will only require one catalog access for > each index shift. Now it looks like it goes to catalog for every column > after the dropped one. Thanks for testing. > What about convert_tuples_by_name_map, do you plan to switch it to catalog > lookups as well? Syscache? I didn't really see an obvious way to get the relids down to the function. e.g the call through ExecEvalConvertRowtype() -> convert_tuples_by_name() does not have a Relation to work with, just a TupleDesc. I think further work might be diminishing returns. I think your idea to reduce the loops in test 6 from 2000 down to 1001 should be worth it. I'll try the idea out next week. -- David Rowley http://www.2ndQuadrant.com/ PostgreSQL Development, 24x7 Support, Training & Services
В списке pgsql-hackers по дате отправления: