From: Amit Langote <Langote_Amit_f8@lab.ntt.co.jp>
To: Corey Huinker <corey.huinker@gmail.com>
Cc: pgsql-hackers@postgresql.org
Subject: Re: Declarative partitioning
Date: Tue, 16 Feb 2016 09:28:23 +0900
Message-ID: <56C26D27.40108@lab.ntt.co.jp> (raw)
In-Reply-To: <CADkLM=cLntJWEzCjW1LUbnRAYz6+-ZooO0FXKg+7rdkTaVE+2g@mail.gmail.com>
References: <55D3093C.5010800@lab.ntt.co.jp>
<56A23484.4000504@2ndquadrant.com>
<56A9D51E.2000508@lab.ntt.co.jp>
<56C1302D.6070403@lab.ntt.co.jp>
<CADkLM=cLntJWEzCjW1LUbnRAYz6+-ZooO0FXKg+7rdkTaVE+2g@mail.gmail.com>
List-Unsubscribe: <mailto:majordomo@postgresql.org?body=unsub%20pgsql-hackers>
Hi Corey,
On 2016/02/16 5:15, Corey Huinker wrote:
>>
>> The individual patches have commit messages that describe code changes.
>> This is registered in the upcoming CF. Feedback and review is greatly
>> welcomed!
>>
> We have a current system that is currently a mix of tables, each of which
> is range partitioned into approximately 15 partitions (using the pgxn range
> partitioning extension), and those partitions are themselves date-series
> partitioned via pg_partman. The largest table ingests about 100M rows per
> day in a single ETL. I will try this patch out and see how well it compares
> in handling the workload. Do you have any areas of interest or concern that
> I should monitor?
Thanks a lot for willing to give it a spin!
I would say this patch series is more geared toward usability. For
example, you won't have to write a trigger to route tuples to correct
partitions. You can try your mentioned ETL load and see if the patch's
implementation of tuple routing fares any better than existing
trigger-based approach. Maybe, you were expecting something like load into
a stand-alone table and then ALTER TABLE INHERIT to instantly load into
the partitioned table (roll-in), but that command is not yet implemented
(ATTACH PARTITION command will show a "not implemented" error message).
Also, you won't see any optimizer and executor changes. Queries will still
use the same plans as existing inheritance-based partitioned tables,
although as I mentioned, constraint exclusion won't yet kick in. That will
be fixed very shortly.
And of course, comments on syntax are welcome as well.
Thanks,
Amit
--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-hackers
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: Langote_Amit_f8@lab.ntt.co.jp, corey.huinker@gmail.com
Subject: Re: Declarative partitioning
In-Reply-To: <56C26D27.40108@lab.ntt.co.jp>
* 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