| From: | Michael Paquier <michael(at)paquier(dot)xyz> |
|---|---|
| To: | Julien Rouhaud <rjuju123(at)gmail(dot)com> |
| Cc: | Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us>, Georgios <gkokolatos(at)protonmail(dot)com>, Julien Rouhaud <julien(dot)rouhaud(at)free(dot)fr>, PostgreSQL Hackers <pgsql-hackers(at)lists(dot)postgresql(dot)org>, "robertmhaas(at)gmail(dot)com" <robertmhaas(at)gmail(dot)com> |
| Subject: | Re: Shared memory size computation oversight? |
| Date: | 2021-03-04 07:05:10 |
| Message-ID: | YECGppkDKJArPOUb@paquier.xyz |
| Views: | Raw Message | Whole Thread | Download mbox | Resend email |
| Thread: | |
| Lists: | pgsql-hackers |
On Thu, Mar 04, 2021 at 12:40:52AM +0800, Julien Rouhaud wrote:
> On Wed, Mar 03, 2021 at 11:23:54AM -0500, Tom Lane wrote:
>> I have not looked at this patch, but I think the concern is basically that
>> if we have space-estimation infrastructure that misestimates what it is
>> supposed to estimate, then if that infrastructure is used to estimate the
>> size of any of the "big hog" data structures, we might misestimate by
>> enough that the slop factor wouldn't hide it.
>
> Exactly. And now that I looked deeper I can see that multiple estimates are
> entirely ignoring the padding alignment (e.g. ProcGlobalShmemSize()), which can
> exceed the 6kB originally estimated by Robert.
We are going to have a hard time catching up all the places that are
doing an incorrect estimation, and have an even harder time making
sure that similar errors don't happen in the future. Should we add a
{add,mul}_shmem_size() to make sure that the size calculated is
correctly aligned, that uses CACHELINEALIGN before returning the
result size?
--
Michael
| From | Date | Subject | |
|---|---|---|---|
| Next Message | Jeff Davis | 2021-03-04 07:05:13 | Re: [PATCH] Support empty ranges with bounds information |
| Previous Message | Bharath Rupireddy | 2021-03-04 06:53:22 | Re: EXPLAIN/EXPLAIN ANALYZE REFRESH MATERIALIZED VIEW |