Re: Different execution plan between PostgreSQL 8.2 and 12.5

From: David Rowley <dgrowleyml(at)gmail(dot)com>
To: Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us>
Cc: gzh <gzhcoder(at)126(dot)com>, pgsql-general(at)lists(dot)postgresql(dot)org
Subject: Re: Different execution plan between PostgreSQL 8.2 and 12.5
Date: 2022-08-18 03:38:58
Message-ID: CAApHDvq=UeFaPf-f0dRSDAk8JXRuUZuBOBPm684aLnzvJeihpw@mail.gmail.com
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-general

On Thu, 18 Aug 2022 at 15:32, Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us> wrote:
> The 12.5 plan looks like it thinks that the join condition is not
> hashable --- and probably not mergeable as well, else it would have
> done a mergejoin. This is odd if we assume that the lower()
> outputs are just text. But you haven't said anything about the
> data types involved, nor what locale setting you're using, nor
> what nondefault settings or extensions you might be using, so
> speculation about the cause would just be speculation.

In addition to that, I couldn't help notice that the quoted SQL does
not seem to belong to the explain. The EXPLAIN has a Limit node, but
the query does not. I'm assuming this isn't due to the relations being
views since we don't pull up subqueries with a LIMIT.

The costs for the 12.5 are cheaper than 8.4's, so I imagine the more
likely cause is the planner favouring an early startup plan.

It's probably more likely that lower() is providing the planner with
bad estimates and there's likely far less than the expected rows,
resulting in the LIMIT 10000 being a much larger proportion of the
total rows than the planner expects.

David

In response to

Responses

Browse pgsql-general by date

  From Date Subject
Next Message Adrian Klaver 2022-08-18 04:18:31 Re: Different execution plan between PostgreSQL 8.2 and 12.5
Previous Message Tom Lane 2022-08-18 03:32:22 Re: Different execution plan between PostgreSQL 8.2 and 12.5