Date: Tue, 03 May 2022 14:21:46 +0200
Subject: Re: Useless memoize path generated for unique join on primary keys
From: Benjamin Coutu <ben.coutu@zeyos.com>
To: David Rowley <dgrowleyml@gmail.com>
Cc: pgsql-performance <pgsql-performance@postgresql.org>
Message-ID: <052166fdb31e17b9ef89@zeyos.com>
In-Reply-To: 
 <CAApHDvpPvJ7HwKRPTXhrGbV1bERVQmnf819a6sPLirOBK=4Q-g@mail.gmail.com>
References: 
 <CAApHDvpPvJ7HwKRPTXhrGbV1bERVQmnf819a6sPLirOBK=4Q-g@mail.gmail.com>
MIME-Version: 1.0
Content-Type: text/plain;
	charset="UTF-8"
Content-Transfer-Encoding: quoted-printable
Archived-At: 
 <https://www.postgresql.org/message-id/052166fdb31e17b9ef89%40zeyos.com>
Precedence: bulk

> I'd say it's a pretty different problem. The cache hit ratio
> discussion on that thread talks about underestimating the hit ratio.
> That particular problem could only lead to Memoize plans *not* being
> chosen when they maybe should be. Not the other way around, which is
> your case.
>=20
> create statistics extdataregular_field_index_stats (ndistinct) on
> field, index from extdataregular;
> analyze extdataregular;
>=20
> would likely put that right.=0A=0AThanks David, using extended statistics=
 for both (and only for both) tables solved this problem.=0A=0ABTW, thank y=
ou for all your work on performance in recent releases.