From: | David Rowley <david(dot)rowley(at)2ndquadrant(dot)com> |
---|---|
To: | Alexander Kuzmenkov <a(dot)kuzmenkov(at)postgrespro(dot)ru> |
Cc: | PostgreSQL Hackers <pgsql-hackers(at)lists(dot)postgresql(dot)org> |
Subject: | Re: Generating partitioning tuple conversion maps faster |
Date: | 2018-06-29 17:40:09 |
Message-ID: | CAKJS1f_D3SK4UJMdFCSbgP-wciMCVUiWM=7gXs=_Z6OL6fjtsg@mail.gmail.com |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-hackers |
On 30 June 2018 at 00:22, Alexander Kuzmenkov
<a(dot)kuzmenkov(at)postgrespro(dot)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
From | Date | Subject | |
---|---|---|---|
Next Message | Alvaro Herrera | 2018-06-29 17:52:07 | Re: Concurrency bug in UPDATE of partition-key |
Previous Message | Regina Obe | 2018-06-29 17:30:03 | RE: Regression on PostgreSQL 10 ORDER/GROUP BY expression not found in targetlist |