| From: | Andres Freund <andres(at)anarazel(dot)de> |
|---|---|
| To: | Heikki Linnakangas <hlinnaka(at)iki(dot)fi> |
| Cc: | vignesh C <vignesh21(at)gmail(dot)com>, pgsql-hackers(at)postgresql(dot)org, Thomas Munro <thomas(dot)munro(at)gmail(dot)com>, Melanie Plageman <melanieplageman(at)gmail(dot)com>, Yura Sokolov <y(dot)sokolov(at)postgrespro(dot)ru>, Robert Haas <robertmhaas(at)gmail(dot)com>, David Rowley <dgrowleyml(at)gmail(dot)com> |
| Subject: | Re: refactoring relation extension and BufferAlloc(), faster COPY |
| Date: | 2023-02-11 22:04:13 |
| Message-ID: | 20230211220413.mrbdmlmgmaqzrcff@awork3.anarazel.de |
| Views: | Raw Message | Whole Thread | Download mbox | Resend email |
| Thread: | |
| Lists: | pgsql-hackers |
On 2023-02-11 13:36:51 -0800, Andres Freund wrote:
> Even though it's not a correctness issue, it seems to me that
> DropRelationsAllBuffers() etc ought to check if the buffer is BM_TAG_VALID,
> before doing anything further. Particularly in DropRelationsAllBuffers(), the
> check we do for each buffer isn't cheap. Doing it for buffers that don't even
> have a tag seems .. not smart.
There's a small regression for a single relation, but after that it's a clear
benefit.
32GB shared buffers, empty. The test creates N new relations and then rolls
back.
tps tps
num relations HEAD precheck
1 46.11 45.22
2 43.24 44.87
4 35.14 44.20
8 28.72 42.79
I don't understand the regression at 1, TBH. I think it must be a random code
layout issue, because the same pre-check in DropRelationBuffers() (exercised
via TRUNCATE of a newly created relation), shows a tiny speedup.
| From | Date | Subject | |
|---|---|---|---|
| Next Message | Andres Freund | 2023-02-11 22:20:14 | Re: refactoring relation extension and BufferAlloc(), faster COPY |
| Previous Message | Mark Dilger | 2023-02-11 21:54:56 | Re: Transparent column encryption |