| From: | Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us> |
|---|---|
| To: | Andres Freund <andres(at)anarazel(dot)de> |
| Cc: | pgsql-hackers(at)postgresql(dot)org, Peter Geoghegan <pg(at)bowt(dot)ie> |
| Subject: | Re: BTScanOpaqueData size slows down tests |
| Date: | 2025-04-02 15:36:33 |
| Message-ID: | 883223.1743608193@sss.pgh.pa.us |
| Views: | Raw Message | Whole Thread | Download mbox | Resend email |
| Thread: | |
| Lists: | pgsql-hackers |
Andres Freund <andres(at)anarazel(dot)de> writes:
> Looking at the size of BTScanOpaqueData I am less surprised:
> /* size: 27352, cachelines: 428, members: 17 */
> allocating, zeroing and freeing 28kB of memory for every syscache miss, yea,
> that's gonna hurt.
Ouch! I had no idea it had gotten that big. Yeah, we ought to
do something about that.
> And/or perhaps we could could allocate BTScanOpaqueData.markPos as a whole
> only when mark/restore are used?
That'd be an easy way of removing about half of the problem, but
14kB is still too much. How badly do we need this items array?
Couldn't we just reference the on-page items?
regards, tom lane
| From | Date | Subject | |
|---|---|---|---|
| Next Message | Ryo Kanbayashi | 2025-04-02 15:36:59 | Re: [PATCH] PGSERVICEFILE as part of a normal connection string |
| Previous Message | Bertrand Drouvot | 2025-04-02 15:27:07 | Re: Draft for basic NUMA observability |