From: | "Jonathan S(dot) Katz" <jkatz(at)postgresql(dot)org> |
---|---|
To: | Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us> |
Cc: | Robert Haas <robertmhaas(at)gmail(dot)com>, Amit Langote <amitlangote09(at)gmail(dot)com>, Thomas Reiss <thomas(dot)reiss(at)dalibo(dot)com>, "pgsql-hackers(at)postgresql(dot)org" <pgsql-hackers(at)postgresql(dot)org> |
Subject: | Re: Performance regression with PostgreSQL 11 and partitioning |
Date: | 2018-05-25 21:33:03 |
Message-ID: | D898BC03-4CE0-4A72-A09B-DFE0CD8A23E9@postgresql.org |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | Postg스포츠 토토 사이트SQL |
> On May 25, 2018, at 5:17 PM, Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)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
From | Date | Subject | |
---|---|---|---|
Next Message | Andrew Gierth | 2018-05-25 21:42:54 | Re: assert in nested SQL procedure call in current HEAD |
Previous Message | Joe Conway | 2018-05-25 21:20:13 | Re: Redesigning the executor (async, JIT, memory efficiency) |