Re: Generating partitioning tuple conversion maps faster

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-07-09 07:13:25
Message-ID: CAKJS1f8dtVqerLf+pNgJ9Wt8upY4jV2FRdyc2TPSeWtJjNkYww@mail.gmail.com
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-hackers

On 7 July 2018 at 01:08, Alexander Kuzmenkov <a(dot)kuzmenkov(at)postgrespro(dot)ru> wrote:
> Great. I think we can use the same approach for make_inh_translation_list,
> as in the attached patch. It show some improvement on test 6. I got the
> following tps, median of 11 runs (forgot to turn off fsync though):
>
> test master v3 v4
> 1 414 416 408
> 2 259 409 404
> 3 263 400 405
> 4 417 416 404
> 5 118 311 305
> 6 85 280 303

Nice. I think that's a good idea. Although, I didn't really like the
use of the comma operator you added. I think since TupleDescAttr can't
be NULL we can just do:

(att = TupleDescAttr(new_tupdesc, new_attno))->attisdropped

There's no shortage of other places that do TupleDescAttr(...)-> so I
think that's perfectly fine.

I also did a slight rewording of the comment above that new code. I've
attached v5.

Please feel free to add yourself as an author of this patch in the
commitfest app. You've probably contributed about as much as I have to
this.

--
David Rowley http://www.2ndQuadrant.com/
PostgreSQL Development, 24x7 Support, Training & Services

Attachment Content-Type Size
v5-0001-Improve-performance-of-tuple-conversion-map-gener.patch application/octet-stream 7.1 KB

In response to

Responses

Browse pgsql-hackers by date

  From Date Subject
Next Message Arseny Sher 2018-07-09 07:15:14 Re: Possible bug in logical replication.
Previous Message Taiki Kondo 2018-07-09 07:09:00 RE: Typo in Japanese translation of psql.