Re: A performance regression issue with Memoize - Mailing list pgsql-hackers

From Tom Lane
Subject Re: A performance regression issue with Memoize
Date
Msg-id 819127.1753765048@sss.pgh.pa.us
Whole thread Raw
In response to Re: A performance regression issue with Memoize  (David Rowley <dgrowleyml@gmail.com>)
List pgsql-hackers
David Rowley <dgrowleyml@gmail.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



pgsql-hackers by date:

Previous
From: Kyotaro Horiguchi
Date:
Subject: delimiter inconsistency in generate-wait_event_types.pl
Next
From: shveta malik
Date:
Subject: Re: POC: enable logical decoding when wal_level = 'replica' without a server restart