Re: Performance regression with PostgreSQL 11 and partitioning - Mailing list pgsql-hackers

From Jonathan S. Katz
Subject Re: Performance regression with PostgreSQL 11 and partitioning
Date
Msg-id D898BC03-4CE0-4A72-A09B-DFE0CD8A23E9@postgresql.org
Whole thread Raw
In response to Re: Performance regression with PostgreSQL 11 and partitioning  (Tom Lane <tgl@sss.pgh.pa.us>)
List pgsql-hackers
> On May 25, 2018, at 5:17 PM, Tom Lane <tgl@sss.pgh.pa.us> wrote:
>
> Maybe it's all right to decide that this rejiggering can be left
> for v12 ... did we promise anyone that it's now sane to use thousands
> of partitions?

Per beta release, we’ve only said “improved SELECT query performance due
to enhanced partition elimination during query processing and execution as
well as parallelized partition scans” with the disclaimers of “subject to change
due to beta testing” and “please test and report back.”

In other words, no promises on the above.

However, the question is how common is the above scenario? If you’re doing
partitions by day, it would take awhile to get to 20K. But if you have something
where you have so much inbound data that you need to partition by hour, it
can occur a little bit more quickly (though will still take a couple of years, if you
were to start partitioning today).

Jonathan

pgsql-hackers by date:

Previous
From: Joe Conway
Date:
Subject: Re: Redesigning the executor (async, JIT, memory efficiency)
Next
From: Andrew Gierth
Date:
Subject: Re: assert in nested SQL procedure call in current HEAD