Re: A performance regression issue with Memoize

From: Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us>
To: David Rowley <dgrowleyml(at)gmail(dot)com>
Cc: Richard Guo <guofenglinux(at)gmail(dot)com>, Pg Hackers <pgsql-hackers(at)lists(dot)postgresql(dot)org>
Subject: Re: A performance regression issue with Memoize
Date: 2025-07-29 04:57:28
Message-ID: 819127.1753765048@sss.pgh.pa.us
Views: Whole Thread | Raw Message | Download mbox | Resend email
Thread:
Lists: pgsql-hackers

David Rowley <dgrowleyml(at)gmail(dot)com> writes:
> For the record, I 100% agree that there will always be cases where
> statistics are just unable to represent what is discovered at
> run-time, so having some sort of ability to adapt at run-time seems
> like a natural progression on the evolutionary chain. I just don't
> know if it's the best or best next step to make. I suspect we might be
> skipping a few steps from what we have now if we went there in the
> near future. We don't yet have extended statistics for joins yet, for
> example.

Yeah. There is plenty remaining to be done towards collecting and
applying traditional sorts of statistics. I worry about ideas
such as run-time plan changes because we will have exactly zero
ability to predict what'll happen if the executor starts doing
that. Maybe it'll be great, but what do you do if it isn't?

regards, tom lane

In response to

Browse pgsql-hackers by date

  From Date Subject
Next Message shveta malik 2025-07-29 05:02:35 Re: POC: enable logical decoding when wal_level = 'replica' without a server restart
Previous Message Kyotaro Horiguchi 2025-07-29 04:56:38 delimiter inconsistency in generate-wait_event_types.pl