From: | David Rowley <dgrowleyml(at)gmail(dot)com> |
---|---|
To: | Zhihong Yu <zyu(at)yugabyte(dot)com> |
Cc: | PostgreSQL Developers <pgsql-hackers(at)lists(dot)postgresql(dot)org>, Andres Freund <andres(at)anarazel(dot)de>, Andy Fan <zhihui(dot)fan1213(at)gmail(dot)com>, Alvaro Herrera <alvherre(at)alvh(dot)no-ip(dot)org>, Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us> |
Subject: | Re: Hybrid Hash/Nested Loop joins and caching results from subplans |
Date: | 2021-04-01 10:23:05 |
Message-ID: | CAApHDvo2PDnsx0eecBqVKxnNuFW1rFRKWv+EF+bqNPZEA21ezw@mail.gmail.com |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-hackers |
On Thu, 1 Apr 2021 at 12:49, David Rowley <dgrowleyml(at)gmail(dot)com> wrote:
> I'm off to look at the buildfarm now.
Well, it looks like the buildfarm didn't like the patch much. I had to
revert the patch.
It appears I overlooked some details in the EXPLAIN ANALYZE output
when force_parallel_mode = regress is on. To make this work I had to
change the EXPLAIN output so that it does not show the main process's
cache Hit/Miss/Eviction details when there are zero misses. In the
animals running force_parallel_mode = regress there was an additional
line for the parallel worker containing the expected cache
hits/misses/evictions as well as the one for the main process. The
main process was not doing any work. I took inspiration from
show_sort_info() which does not show the details for the main process
when it did not help with the Sort.
There was also an issue on florican [1] which appears to be due to
that machine being 32-bit. I should have considered that when
thinking of the cache eviction test. I originally tried to make the
test as small as possible by lowering work_mem down to 64kB and only
using enough rows to overflow that by a small amount. I think what's
happening on florican is that due to all the pointer fields in the
cache being 32-bits instead of 64-bits that more records fit into the
cache and there are no evictions. I've scaled that test up a bit now
to use 1200 rows instead of 800.
The 32-bit machines also were reporting a different number of exact
blocks in the bitmap heap scan. I've now just disabled bitmap scans
for those tests.
I've attached the updated patch. I'll let the CFbot grab this to
ensure it's happy with it before I go looking to push it again.
David
[1] https://buildfarm.postgresql.org/cgi-bin/show_log.pl?nm=florican&dt=2021-04-01%2000%3A28%3A12
Attachment | Content-Type | Size |
---|---|---|
v20-0001-Add-Result-Cache-executor-node.patch | text/plain | 156.8 KB |
From | Date | Subject | |
---|---|---|---|
Next Message | houzj.fnst@fujitsu.com | 2021-04-01 10:41:30 | RE: Hybrid Hash/Nested Loop joins and caching results from subplans |
Previous Message | Amit Kapila | 2021-04-01 10:19:01 | Re: Any objections to implementing LogicalDecodeMessageCB for pgoutput? |