pg.ddx.io  pgsql-performance@postgresql.org mailing list archive  

help / color / mirror / Atom feed
From: Tom Lane <tgl@sss.pgh.pa.us>
To: Manuel Weitzman <manuelweitzman@gmail.com>
Cc: Ranier Vilela <ranier.vf@gmail.com>
Cc: David Rowley <dgrowleyml@gmail.com>
Cc: Jeremy Schneider <schnjere@amazon.com>
Cc: pgsql-performance@lists.postgresql.org <pgsql-performance@lists.postgresql.org>
Cc: Andres Freund <andres@anarazel.de>
Subject: Re: Planning performance problem (67626.278ms)
Date: Tue, 29 Jun 2021 15:43:28 -0400
Message-ID: <500142.1624995808@sss.pgh.pa.us> (raw)
In-Reply-To: <39C2266C-3143-4A7A-BCAF-E0C8394F9D24@gmail.com>
References: <6d58f68e-ed1a-c48e-1440-691554f6e1e7@9livesdata.com>
	<CAFj8pRDDnOVNcU7dx4+oKH0x4-DsmL3XRWppQ8Cf5wwJ=G2fPg@mail.gmail.com>
	<20190408144210.GG10080@telsasoft.com>
	<b145b428-3351-ec86-d522-100a5bf8ded7@amazon.com>
	<20190408232644.r6xixkeulsmomwfj@alap3.anarazel.de>
	<3f5e5673-06aa-bf7c-cdb7-0e053c45ba26@amazon.com>
	<CAApHDvq9o1J45is6w-3Gv1UgtuDQ4eQP4UhFPQSnQmEH_EijvQ@mail.gmail.com>
	<767433.1619015825@sss.pgh.pa.us>
	<EFE95962-F088-45E2-BD13-AA5012829A69@gmail.com>
	<F06D0C00-DE75-4688-98B0-85A46E8F312C@gmail.com>
	<CAEudQApVF7TX-EJXwBz4TUhH6NzNB-wXqhs4wj+qSe6Vw3H5-Q@mail.gmail.com>
	<1588548.1624234651@sss.pgh.pa.us>
	<39C2266C-3143-4A7A-BCAF-E0C8394F9D24@gmail.com>

Manuel Weitzman <manuelweitzman@gmail.com> writes:
>> On 20-06-2021, at 17:06, Tom Lane <tgl@sss.pgh.pa.us> wrote:
>> So ... the reason why there's not caching of get_actual_variable_range
>> results already is that I'd supposed it wouldn't be necessary given
>> the caching of selectivity estimates that happens at the RestrictInfo
>> level.  I don't have any objection in principle to adding another
>> caching layer if that one's not working well enough, but I think it'd
>> be wise to first understand why it's needed.

> For what I could make out from the code, the caching done at the
> RestrictInfo level is already saving a lot of work, but there's a
> different RestrictInfo instance for each alternative path created by
> make_one_rel().

That seems a bit broken; a given WHERE clause should produce only one
RestrictInfo.  Can you provide a more concrete example?

			regards, tom lane





view thread (12+ messages)  latest in thread

Message-ID: <500142.1624995808@sss.pgh.pa.us>
Permalink:  ../500142.1624995808@sss.pgh.pa.us/
Also on:    postgresql.org/message-id/500142.1624995808@sss.pgh.pa.us

 · 

reply
Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Reply to all the recipients using the --to and --cc options:
  reply via email

  To: pgsql-performance@postgresql.org
  Cc: tgl@sss.pgh.pa.us, manuelweitzman@gmail.com, ranier.vf@gmail.com, dgrowleyml@gmail.com, schnjere@amazon.com, pgsql-performance@lists.postgresql.org, andres@anarazel.de
  Subject: Re: Planning performance problem (67626.278ms)
  In-Reply-To: <500142.1624995808@sss.pgh.pa.us>

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

This inbox is served by DDX for PostgreSQL; see mirroring instructions
for how to clone and mirror all data and code used for this inbox