From: Tom Lane <tgl@sss.pgh.pa.us>
To: nico@cryptonector.com
cc: pgsql-bugs@lists.postgresql.org
Subject: Re: BUG #18825: Row value equality predicates do not use indices
In-reply-to: <18825-5c25a6ba19fa6549@postgresql.org>
References: <18825-5c25a6ba19fa6549@postgresql.org>
Comments: In-reply-to PG Bug reporting form <noreply@postgresql.org>
	message dated "Tue, 25 Feb 2025 22:24:36 +0000"
MIME-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
Content-ID: <1678854.1740530682.1@sss.pgh.pa.us>
Date: Tue, 25 Feb 2025 19:44:42 -0500
Message-ID: <1678855.1740530682@sss.pgh.pa.us>
Archived-At: 
 <https://www.postgresql.org/message-id/1678855.1740530682%40sss.pgh.pa.us>
Precedence: bulk

PG Bug reporting form <noreply@postgresql.org> writes:
> DELETE FROM foo USING (SELECT dels FROM dels) AS dels
> WHERE foo = dels; -- <--- does not use indices on either table

[ shrug... ]  Works for me given the full-row indexes, although I do
have to force enable_seqscan off or reduce random_page_cost a lot,
because otherwise the planner thinks a seqscan-and-sort is cheaper.
I strongly suspect it's right, because full-row indexes are going to
be bigger than the table proper.  The mere fact that a plan uses
indexes does not automatically make it better than one that doesn't.

Anyway, AFAICS your gripe has nothing to do with "can the planner
use these indexes", and everything to do with its cost estimates
about the value of doing it that way.

			regards, tom lane