On Thu, 22 Jul 2021 at 16:37, l...@laurent-hasson.com
wrote:
> Seems like no cigar ☹ See plan pasted below. I changed the conf as follows:
> - hash_mem_multiplier = '2'
> - work_mem = '1GB'
> Batches: 5 Memory Usage: 2400305kB Disk Usage: 126560kB
You might want to keep going
-Original Message-
From: l...@laurent-hasson.com
Sent: Wednesday, July 21, 2021 19:46
To: Tom Lane
Cc: Peter Geoghegan ; Justin Pryzby ;
pgsql-performa...@postgresql.org
Subject: RE: Big performance slowdown from 11.2 to 13.3
-Original Message-
From: Tom Lane
Sent:
-Original Message-
From: Tom Lane
Sent: Wednesday, July 21, 2021 19:43
To: l...@laurent-hasson.com
Cc: Peter Geoghegan ; Justin Pryzby ;
pgsql-performa...@postgresql.org
Subject: Re: Big performance slowdown from 11.2 to 13.3
"l...@laurent-hasson.com" writes:
> From: Peter
-Original Message-
From: Tom Lane
Sent: Wednesday, July 21, 2021 19:36
To: l...@laurent-hasson.com
Cc: Justin Pryzby ; pgsql-performa...@postgresql.org
Subject: Re: Big performance slowdown from 11.2 to 13.3
"l...@laurent-hasson.com" writes:
> My apologies... I thought this is what
"l...@laurent-hasson.com" writes:
> From: Peter Geoghegan
>> I imagine that this has something to do with the fact that the hash
>> aggregate spills to disk in Postgres 13.
> So how is this happening? I mean, it's the exact same query, looks like the
> same plan to me, it's the same data on
-Original Message-
From: Peter Geoghegan
Sent: Wednesday, July 21, 2021 19:34
To: l...@laurent-hasson.com
Cc: Justin Pryzby ; pgsql-performa...@postgresql.org
Subject: Re: Big performance slowdown from 11.2 to 13.3
On Wed, Jul 21, 2021 at 4:19 PM l...@laurent-hasson.com
wrote:
> As
"l...@laurent-hasson.com" writes:
> My apologies... I thought this is what I had attached in my original email
> from PGADMIN. In any case, I reran from the command line and here are the two
> plans.
So the pain seems to be coming in with the upper hash aggregation, which
is spilling to disk
On Wed, Jul 21, 2021 at 4:19 PM l...@laurent-hasson.com
wrote:
> As you can see, the V13.3 execution is about 10x slower.
>
> It may be hard for me to create a whole copy of the database on 11.12 and
> check that environment by itself. I'd want to do it on the same machine to
> control
From: Michael Lewis
Sent: Wednesday, July 21, 2021 18:12
To: l...@laurent-hasson.com
Cc: pgsql-performa...@postgresql.org
Subject: Re: Big performance slowdown from 11.2 to 13.3
I'm not seeing the valueof the CTE. Why not access assessmenticcqa_raw directly
in the main query and only do GROUP
-Original Message-
From: Justin Pryzby
Sent: Wednesday, July 21, 2021 15:15
To: l...@laurent-hasson.com
Cc: pgsql-performa...@postgresql.org
Subject: Re: Big performance slowdown from 11.2 to 13.3
On Wed, Jul 21, 2021 at 06:50:58PM +, l...@laurent-hasson.com wrote:
> The plans are
I'm not seeing the valueof the CTE. Why not access assessmenticcqa_raw
directly in the main query and only do GROUP BY once? Do you have many
values in iccqar_ques_code which are not used in this query?
>
On Wed, Jul 21, 2021 at 06:50:58PM +, l...@laurent-hasson.com wrote:
> The plans are pretty much identical too. I checked line by line and couldn't
> see anything much different (note that I have a view over this query). Here
> is the V13 version of the plan:
> I am out of my wits as to
Hello,
We have a data warehouse working on Postgres V11.2. We have a query that is
pretty beefy that has been taking under 5mn to run consistently every day for
about 2 years as part of a data warehouse ETL process. It's a pivot over 55
values on a table with some 15M rows. The total table
"Dirschel, Steve" writes:
> I have a sample query that is doing more work if some of the reads are
> physical reads and I'm trying to understand why. If you look at attached
> QueryWithPhyReads.txt it shows the query did Buffers: shared hit=171
> read=880. So it did 171 + 880 = 1051 total
New to Postgres, Oracle background. With Oracle the amount of work a query
does is tracked via logical reads. Oracle tracks logical and physical reads
differently than Postgres. With Oracle a physical read is always considered a
logical read. So if a query reads 5 blocks are all 5 are read
15 matches
Mail list logo
