On Fri, Dec 7, 2018 at 11:13 AM Ashutosh Bapat
wrote:
>
>
>
>>
>>
>> Robert, Ashutosh, any comments on this? I'm unfamiliar with the
>> partitionwise join code.
>>
>
> As the comment says it has to do with the equivalence classes being used
> during merge append. EC's are used to create
On Thu, Dec 6, 2018 at 1:27 PM Alvaro Herrera
wrote:
> On 2018-Dec-06, Amit Langote wrote:
>
> > The partitionwise join related
> > changes in PG 11 moved the add_child_rel_equivalences call in
> > set_append_rel_size such that child EC members would be added even before
> > checking if the
On 2018-Dec-06, Amit Langote wrote:
Hi
> [ Parallel SeqScan on precio_126 to precio_998 ]
>
> > -> Parallel Seq Scan on precio_999 p_874
> > (cost=0.00..27.50 rows=1 width=16)
> >Filter: ((fecha >= '1990-05-06
> > 00:00:00'::timestamp
Hi,
(Re-sending after adding -hackers, sorry for the noise to those who would
receive this twice)
On 2018/12/05 6:55, Alvaro Herrera wrote:
> I noticed another interesting thing, which is that if I modify the query
> to actually reference some partition that I do have (as opposed to the
> above,
Hi,
On 2018/12/05 6:55, Alvaro Herrera wrote:
> On 2018-Dec-04, Alvaro Herrera wrote:
>
>> CREATE TABLE precio(fecha timestamp, pluid int, loccd int, plusalesprice
>> int) PARTITION BY RANGE (fecha);
>> SELECT format('CREATE TABLE public.precio_%s PARTITION OF public.precio
>> (PRIMARY KEY
pá 30. 11. 2018 v 15:37 odesílatel Sanyo Moura
napsal:
> Hello again,
>
> At the moment, I've got a palliative solution that has significantly
> reduced my planning time.
> What I did was nest the partitions by creating sub partitions.
> That way, my 730 partitions (2 years of data) were
Em qua, 28 de nov de 2018 às 22:40, Justin Pryzby
escreveu:
> On Wed, Nov 28, 2018 at 05:03:15PM +1300, David Rowley wrote:
> > 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
On Wed, Nov 28, 2018 at 05:03:15PM +1300, David Rowley wrote:
> 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
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:
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 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.
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 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
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 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
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
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
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
21 matches
Mail list logo
