| From: | Thomas Munro <thomas(dot)munro(at)gmail(dot)com> |
|---|---|
| To: | Melanie Plageman <melanieplageman(at)gmail(dot)com> |
| Cc: | Tomas Vondra <tomas(dot)vondra(at)enterprisedb(dot)com>, Heikki Linnakangas <hlinnaka(at)iki(dot)fi>, Andres Freund <andres(at)anarazel(dot)de>, Pg Hackers <pgsql-hackers(at)postgresql(dot)org>, Nazir Bilal Yavuz <byavuz81(at)gmail(dot)com> |
| Subject: | Re: BitmapHeapScan streaming read user and prelim refactoring |
| Date: | 2024-03-28 05:20:27 |
| Message-ID: | CA+hUKGLg_QRgQONVTbRCZC3xRdbuWXtQkVaR+cg0zBxSLoJcRg@mail.gmail.com |
| Views: | Raw Message | Whole Thread | Download mbox | Resend email |
| Thread: | |
| Lists: | pgsql-hackers |
With the unexplained but apparently somewhat systematic regression
patterns on certain tests and settings, I wonder if they might be due
to read_stream.c trying to form larger reads, making it a bit lazier.
It tries to see what the next block will be before issuing the
fadvise. I think that means that with small I/O concurrency settings,
there might be contrived access patterns where it loses, and needs
effective_io_concurrency to be set one notch higher to keep up, or
something like that. One way to test that idea would be to run the
tests with io_combine_limit = 1 (meaning 1 block). It issues advise
eagerly when io_combine_limit is reached, so I suppose it should be
exactly as eager as master. The only difference then should be that
it automatically suppresses sequential fadvise calls.
| From | Date | Subject | |
|---|---|---|---|
| Next Message | Amit Langote | 2024-03-28 05:23:09 | Re: remaining sql/json patches |
| Previous Message | jian he | 2024-03-28 05:18:41 | Re: Can't find not null constraint, but \d+ shows that |