Hi Shira,
there's the number of shared buffers involved in the hash aggregation that
is different in the two execution plans, in PostgreSQL 9.6 the double of
the pages are hitten compared to PostgreSQL 12.0. Here I assume that the
configuration of the two DB engines is the same (same shared
Yeah, I noticed that. Yes, both tables have the same number of rows
(2,502). That 15,812 number is showing up in the 12 plan in the ProjectSet
node.
Shira
On Thu, Jan 9, 2020 at 1:24 PM Paul Ramsey
wrote:
> according to the explain the seqscan at the bottom of the plan is scanning
> and
according to the explain the seqscan at the bottom of the plan is scanning and
returning only 5x more rows in 9.6. are the tables really the same size?
> On Jan 9, 2020, at 12:47 PM, Shira Bezalel wrote:
>
> Hi List,
>
> This is a "yeah, but why?" type of question.
>
> I'm testing an
Hi Paul,
The links I provided go to EXPLAIN ANALYZE output. No parallelism showing
up.
Thank you,
Shira
On Thu, Jan 9, 2020 at 1:13 PM Paul Ramsey
wrote:
> EXPLAIN ANALYZE the query.
> My data-free guess is that, since you’ve got an aggregate function in
> there, is you’re getting a parallel
EXPLAIN ANALYZE the query.
My data-free guess is that, since you’ve got an aggregate function in there, is
you’re getting a parallel plan under the aggregate, that’s something you
wouldn’t get in 9.6 but would in 12. I don’t think there’s been any substantial
change in the PostGIS raster code,
Hi List,
This is a "yeah, but why?" type of question.
I'm testing an upgrade from
Postgres 9.6 and PostGIS 2.3
to
Postgres 12.1 and PostGIS 3.0
One of our queries has gone from about 80 seconds to 30 seconds on the new
releases, which is great, but I'm just trying to figure out why. I
Solution is to filter out NULL returned when using ST_Value() or DISTINCT or
GROUP BY multiple values returned when using ST_Intersect().
Using (only) one solution consistently returns consistent results.
Pierre
-Message d'origine-
De : postgis-users De la part de Peter
Devoy
Envoyé
