Hello Tom,
Both versions 10.5 and 11.1 are running on the same test server.
What I did was migrate the database from 10.5 to 11.1 via pg_upgrade. After
successful execution, I performed "vacuumdb --all --analyze-in-stages".
Thanks,
Sanyo Capobiango
Em ter, 27 de nov de 2018 às 13:00, Tom Lane
Sanyo Moura writes:
> And below are the times generated by EXPLAIN ANALYZE:
> 10.5
> Planning time: 126.080 ms
> Execution time: 2.306 ms
> 11.0
> Planning Time: 7.238 ms
> Planning Time: 2.638 ms
> 11.5(I assume you mean 11.1 here)
> Planning Time: 15138.533 ms
> Execution Time: 2.310
On Tue, Nov 27, 2018 at 9:17 AM Sanyo Moura wrote:
> Hi,
>
> I'm running performance tests for my application at version 11.1 and
> encountered
> queries with high planning time compared to the same planning, running at
> versions 10.5 and 11.0.
>
Can you reproduce the regression if the tables
On Tue, Nov 27, 2018 at 06:30:04PM -0200, Sanyo Moura wrote:
>>> I'm running performance tests for my application at version 11.1 and
>>> encountered
>>> queries with high planning time compared to the same planning, running at
>>> versions 10.5 and 11.0.
>
> Below is the script that creates one
Hello Jeff,
My table (PRICE) is partitioned and contains 730 partitions. Each partition
contains 1 day of data.
I performed the same test now with restriction (WHERE) in only 1 day (1
partition), but doing SELECT in the virtual table PRICE.
I got the same delay in planning.
However, when I
Hello again Jeff,
Below is the script that creates one partition table:
CREATE TABLE public.precio_20170301 PARTITION OF public.precio
(
CONSTRAINT precio_20170301_pkey PRIMARY KEY (fecha, pluid, loccd),
CONSTRAINT precio_20170301_almacen_fk FOREIGN KEY (loccd)
REFERENCES
On Tue, Nov 27, 2018 at 9:17 AM Sanyo Moura wrote:
>>> I'm running performance tests for my application at version 11.1 and
>>> encountered queries with high planning time compared to the same planning,
>>> running at versions 10.5 and 11.0.
I was able to reproduce this behavior.
For my version
I currently have version 11.1 and 10.6 running on the same linux server. In
both Postgres the "Price" table has 730 partitions.
However, in the test I did in version 11.0, "Precio" is partitioned into
only 21 partitions. So it really is a problem introduced in version 11, and
it has to do with a
On Tue, Nov 27, 2018 at 06:44:02PM -0600, Justin Pryzby wrote:
> On Tue, Nov 27, 2018 at 9:17 AM Sanyo Moura wrote:
> >>> I'm running performance tests for my application at version 11.1 and
> >>> encountered queries with high planning time compared to the same planning,
> >>> running at versions
Thanks a lot Justin,
At this moment I can not help you with what you asked for, but tomorrow
morning I will send other information.
I believe Postgres 11.1 is somehow taking a lot of planning time when
analyzing which partitions are needed in execution.
Sanyo
Em ter, 27 de nov de 2018 às 22:44,
On Tue, Nov 27, 2018 at 11:36:09PM -0200, Sanyo Moura wrote:
> However, in the test I did in version 11.0, "Precio" is partitioned into
> only 21 partitions. So it really is a problem introduced in version 11, and
> it has to do with a large number of partitions in a table.
Thanks for confirming.
On Wed, 28 Nov 2018 at 03:16, Sanyo Moura wrote:
> 11.0
> Planning Time: 7.238 ms
> Planning Time: 2.638 ms
>
> 11.5
> Planning Time: 15138.533 ms
> Execution Time: 2.310 ms
Does it still take that long after running ANALYZE on the partitioned table?
--
David Rowley
On Wed, Nov 28, 2018 at 05:03:15PM +1300, David Rowley wrote:
> Does it still take that long after running ANALYZE on the partitioned table?
Yes ; I've just reproduced the problem with a variation on Sanyo's query,
retrofitted onto the empty "partbench" table you used for testing in July:
13 matches
Mail list logo
