| From: | Thomas Munro <thomas(dot)munro(at)gmail(dot)com> |
|---|---|
| To: | Tomas Vondra <tomas(dot)vondra(at)enterprisedb(dot)com> |
| Cc: | Melanie Plageman <melanieplageman(at)gmail(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-29 13:36:08 |
| Message-ID: | CA+hUKG+QcN9AfW+v5isNMEBJr34VPOWifyC-LX=tLN4Ddh_Srw@mail.gmail.com |
| Views: | Raw Message | Whole Thread | Download mbox | Resend email |
| Thread: | |
| Lists: | pgsql-hackers |
On Sat, Mar 30, 2024 at 12:17 AM Thomas Munro <thomas(dot)munro(at)gmail(dot)com> wrote:
> eic unpatched patched
> 0 4172 9572
> 1 30846 10376
> 2 18435 5562
> 4 18980 3503
> 8 18980 2680
> 16 18976 3233
... but the patched version gets down to a low number for eic=0 too if
you turn up the blockdev --setra so that it also gets Linux RA
treatment, making it the clear winner on all eic settings. Patched
doesn't improve. So, for low IOPS storage at least, when you're on
the borderline between random and sequential, ie bitmap with a lot of
1s in it, it seems there are cases where patched doesn't trigger Linux
RA but unpatched does, and you can tune your way out of that, and then
there are cases where the IOPS limit is reached due to small reads,
but patched does better because of larger I/Os that are likely under
the same circumstances. Does that make sense?
| From | Date | Subject | |
|---|---|---|---|
| Next Message | Robert Haas | 2024-03-29 13:40:08 | Re: documentation structure |
| Previous Message | Pavel Borisov | 2024-03-29 13:21:23 | Re: [HACKERS] make async slave to wait for lsn to be replayed |