pg.ddx.io  pgsql-hackers@postgresql.org mailing list archive  

help / color / mirror / Atom feed
From: Jesper Pedersen <jesper.pedersen@redhat.com>
To: Amit Langote <Langote_Amit_f8@lab.ntt.co.jp>
Cc: Imai, Yoshikazu <imai.yoshikazu@jp.fujitsu.com>
Cc: Amit Langote <amitlangote09@gmail.com>
Cc: Tom Lane <tgl@sss.pgh.pa.us>
Cc: David Rowley <david.rowley@2ndquadrant.com>
Cc: Alvaro Herrera <alvherre@2ndquadrant.com>
Cc: Justin Pryzby <pryzby@telsasoft.com>
Cc: Pg Hackers <pgsql-hackers@postgresql.org>
Subject: Re: speeding up planning with partitions
Date: Tue, 5 Mar 2019 10:57:57 -0500
Message-ID: <dcda0c1b-6360-193d-9c94-0113b0b905a1@redhat.com> (raw)
In-Reply-To: <ee0c1d07-e2bc-57af-6dd7-852eba7df61c@lab.ntt.co.jp>
References: <CAKJS1f9XAePd2+8F4=wtHKdDdckgKcSoXb-ZbU8Wbt86mhLxKA@mail.gmail.com>
	<b8a139b8-2f5d-6079-67b2-99957af3fc36@lab.ntt.co.jp>
	<7453.1550518972@sss.pgh.pa.us>
	<0a70234e-b2e6-debc-2fb5-e8fd927caa00@lab.ntt.co.jp>
	<1002.1550596071@sss.pgh.pa.us>
	<30961.1550609873@sss.pgh.pa.us>
	<250c61bc-479c-92f4-d19d-d768e3bcdcbc@lab.ntt.co.jp>
	<13510.1550677844@sss.pgh.pa.us>
	<a47e6214-bd46-ab4b-2f84-f9f726e04642@lab.ntt.co.jp>
	<35b02675-83c2-a12b-961a-fec249b06f35@lab.ntt.co.jp>
	<20190222165932.GG28750@telsasoft.com>
	<CA+HiwqEUwfg4s=4=is-+7k-WM-2Gs9K3iFB96QNm_eafcBozqQ@mail.gmail.com>
	<0F97FA9ABBDBE54F91744A9B37151A51293422@g01jpexmbkw24>
	<8098beec-fc04-303d-55b9-73c3d94ba1ea@lab.ntt.co.jp>
	<b5362c29-cca1-de7b-13d0-9e51f9911185@lab.ntt.co.jp>
	<ce7bb7c2-8eac-0047-1e04-e771f08ad1fb@redhat.com>
	<0bb0f410-bfbc-3ee5-946b-43e89e8cbd57@lab.ntt.co.jp>
	<ee0c1d07-e2bc-57af-6dd7-852eba7df61c@lab.ntt.co.jp>

On 3/5/19 5:24 AM, Amit Langote wrote:
> Attached an updated version.  This incorporates fixes for both Jesper's
> and Imai-san's review.  I haven't been able to pin down the bug (or
> whatever) that makes throughput go down as the partition count increases,
> when tested with a --enable-cassert build.
> 

Thanks !

I'm seeing the throughput going down as well, but are you sure it isn't 
just the extra calls of MemoryContextCheck you are seeing ? A flamegraph 
diff highlights that area -- sent offline.

A non cassert build shows the same profile for 64 and 1024 partitions.

Best regards,
  Jesper




view thread (265+ messages)  latest in thread

Message-ID: <dcda0c1b-6360-193d-9c94-0113b0b905a1@redhat.com>
Permalink:  ../dcda0c1b-6360-193d-9c94-0113b0b905a1@redhat.com/
Also on:    postgresql.org/message-id/dcda0c1b-6360-193d-9c94-0113b0b905a1@redhat.com

 · 

reply
Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Reply to all the recipients using the --to and --cc options:
  reply via email

  To: pgsql-hackers@postgresql.org
  Cc: jesper.pedersen@redhat.com, Langote_Amit_f8@lab.ntt.co.jp, imai.yoshikazu@jp.fujitsu.com, amitlangote09@gmail.com, tgl@sss.pgh.pa.us, david.rowley@2ndquadrant.com, alvherre@2ndquadrant.com, pryzby@telsasoft.com
  Subject: Re: speeding up planning with partitions
  In-Reply-To: <dcda0c1b-6360-193d-9c94-0113b0b905a1@redhat.com>

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

This inbox is served by DDX for PostgreSQL; see mirroring instructions
for how to clone and mirror all data and code used for this inbox