Received: from malur.postgresql.org ([217.196.149.56]) by arkaria.postgresql.org with esmtps (TLS1.3:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.92) (envelope-from ) id 1pUDFE-0001iu-Vc for pgsql-bugs@arkaria.postgresql.org; Mon, 20 Feb 2023 20:58:44 +0000 Received: from localhost ([127.0.0.1] helo=malur.postgresql.org) by malur.postgresql.org with esmtp (Exim 4.92) (envelope-from ) id 1pUDFD-0005wm-QF for pgsql-bugs@arkaria.postgresql.org; Mon, 20 Feb 2023 20:58:43 +0000 Received: from magus.postgresql.org ([2a02:c0:301:0:ffff::29]) by malur.postgresql.org with esmtps (TLS1.3:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.92) (envelope-from ) id 1pUDFD-0005wd-H0 for pgsql-bugs@lists.postgresql.org; Mon, 20 Feb 2023 20:58:43 +0000 Received: from tamriel.snowman.net ([2001:470:e38f::11]) by magus.postgresql.org with esmtp (Exim 4.92) (envelope-from ) id 1pUDF8-0007JP-5J for pgsql-bugs@lists.postgresql.org; Mon, 20 Feb 2023 20:58:43 +0000 Received: by tamriel.snowman.net (Postfix, from userid 1000) id E04E95F7BC; Mon, 20 Feb 2023 15:58:36 -0500 (EST) Date: Mon, 20 Feb 2023 15:58:36 -0500 From: Stephen Frost To: Charles Cc: Tom Lane , pgsql-bugs@lists.postgresql.org Subject: Re: Query run in 27s with 15.2 vs 37ms with 14.6 Message-ID: References: <3573388.1676909470@sss.pgh.pa.us> MIME-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-sha512; protocol="application/pgp-signature"; boundary="GNYoGczoL34O0sNZ" Content-Disposition: inline In-Reply-To: User-Agent: Mutt/2.1.4 (2021-12-11) List-Id: List-Help: List-Subscribe: List-Post: List-Owner: List-Archive: Archived-At: Precedence: bulk --GNYoGczoL34O0sNZ Content-Type: text/plain; charset=us-ascii Content-Disposition: inline Content-Transfer-Encoding: quoted-printable Greetings, * Charles (peacech@gmail.com) wrote: > Wrapping the query with a select * from (...) t where length(code) =3D 4 = puts > the execution time back to 27 seconds. >=20 > This is a bit unexpected since I expect that the result from the inner > query to be executed first and then filtered. It's really not- PG will (correctly) attempt to pull in such subselects into the overall optimization, which is generally better for everyone. If you want to force it, you can use a WITH MATERIALIZED CTE, or throw in an 'OFFSET 0' as a hack into your sub-select, but really it's a much better idea to generate extended stats on what you're filtering as has been suggested, or come up with a better data representation where you're not doing a search on a 'length()' as you are. Thanks, Stephen --GNYoGczoL34O0sNZ Content-Type: application/pgp-signature; name="signature.asc" -----BEGIN PGP SIGNATURE----- iQIzBAABCgAdFiEEwf6gbxKhD863zrx/7WyKOINHZFUFAmPz3vgACgkQ7WyKOINH ZFW+FA/+P82hhXoq380l/ykroDyQJz+tmI1/Ym3RTs4CnJdE1QNsTjeCtf4wl1Sz 1jECm4pr6Lku6MPfHBuj25a1J+fHs6WbYseIaW5Qf9qqLGwnH3wTQ3M5RHb8huia b75ub58X+1CPCzVSOGvN3QVR6ekKbP4gnUDW2OZEkROOby+77QfklWvFPkBYbmTu 7eZrthPbBzmSRlWFQuMUnSzpOJur4gtHR1YnYdj3TiIdrKRA0008qIvD380/7ZwT jeV+HuD76kgoS3ksoxwsOFlasJVVH6Z847b4Ls3KVsgMHbntr9oYnaVPYlzzvUsc DWsz0Puz0TCjuLQjo/MIEopmFKTkVuoU5KqH6QpaAgQ60qBeBQ7yCkwjGleI8sno 05OtyBM1hNMEhlmNCQN/RgGyxlWy7QMmOjP1EDSoERT0lan3/dkQcUmJCin0R2R+ fNammrb+bqbMJysVEo0Xpu0BiDvFlkaNm8D5+dDh2hjIJcolwU93vV5wRIjVU+Ek aSOEyjW6QzUZmPJmU9ykTMhIajH1AOHhqEL/87UT+ro1v+ks2QPwhYwFgsjSNO6v obMgc/g+L6CLK0uXEm8pPHtsdI4Y32lHO8rG6WtUsnPUAVvWgj5TDYfdFT0Vbz73 Z8yXMH6gi5uxtI3UwKVTfEve6hKSiTFuYu4dJ2zntzpfKSqG7wc= =ahjU -----END PGP SIGNATURE----- --GNYoGczoL34O0sNZ--