Reported-by: John Naylor

Discussion: https://postgr.es/m/CAFBsxsE-US0sgVxVHjt99GCGky4TCD57gwMHWPF9XWo7R5rXPg@mail.gmail.com

Source-Git-URL: https://git.postgresql.org/git/pgtranslation/messages.git
Source-Git-Hash: dde45df385dab9032155c1f867b677d55695310c

Forgot to add it in one place in the previous commit.

prep_status_progress() is new.

In order to estimate the cache hit ratio of a Memoize node, one of the
inputs we require is the estimated number of times the Memoize node will
be rescanned.  The higher this number, the large the cache hit ratio is
likely to become.  Unfortunately, the value being passed as the number of
"calls" to the Memoize was incorrectly using the Nested Loop's
outer_path->parent->rows instead of outer_path->rows.  This failed to
account for the fact that the outer_path might be parameterized by some
upper-level Nested Loop.

This problem could lead to Memoize plans appearing more favorable than
they might actually be.  It could also lead to extended executor startup
times when work_mem values were large due to the planner setting overly
large MemoizePath->est_entries resulting in the Memoize hash table being
initially made much larger than might be required.

Fix this simply by passing outer_path->rows rather than
outer_path->parent->rows.  Also, adjust the expected regression test
output for a plan change.

Reported-by: Pavel Stehule
Author: David Rowley
Discussion: https://postgr.es/m/CAFj8pRAMp%3DQsMi6sPQJ4W3hczoFJRvyXHJV3AZAZaMyTVM312Q%40mail.gmail.com
Backpatch-through: 14, where Memoize was introduced

Reaction to a suggestion from jhebert@micron.com, though this doesn't
directly address the complaint.

Discussion: https://postgr.es/m/165117307860.683.10308862820133754390@wrigleys.postgresql.org

Suggested by David G. Johnston <david.g.johnston@gmail.com>

Discussion: https://postgr.es/m/CAKFQuwYK4OqwoHscZi3yws-urv3NvVfoKHessyso5D=5qqChYQ@mail.gmail.com

Per BF animal chipmunk:  CREATE DATABASE could apparently fail due to an
AV process being in the template database and not quitting fast enough
for the 5 second timeout in CountOtherDBBackends().  The test script had
autovacuum_naptime=1s to encourage more activity and opening of fds, but
that wasn't strictly necessary for this test.  Take it out.

Per BF animal skink:  there was a 300s timeout for all tests in the
script, but apparently that was not enough under valgrind.  Let's use
the standard timeout $PostgreSQL::Test::Utils::timeout_default, but
restart it for each query we run.

Reviewed-by: Robert Haas <robertmhaas@gmail.com>
Discussion: https://postgr.es/m/CA%2BhUKGKa8HNJaA24gqiiFoGy0ysndeVoJsHvX_q1-DVLFaGAmw%40mail.gmail.com