| From: | Matthias van de Meent <boekewurm+postgres(at)gmail(dot)com> |
|---|---|
| To: | Darafei Komяpa Praliaskouski <me(at)komzpa(dot)net> |
| Cc: | Nikolay Samokhvalov <nik(at)postgres(dot)ai>, pgsql-hackers <pgsql-hackers(at)lists(dot)postgresql(dot)org>, Kirk Wolak <wolakk(at)gmail(dot)com>, Andrey Borodin <amborodin(at)acm(dot)org>, aekorotkov(at)gmail(dot)com |
| Subject: | Re: Missing wait events (gap analysis) |
| Date: | 2025-11-24 16:45:13 |
| Message-ID: | CAEze2WiarbHsd=jJKWD6x0LZnC1c4E+vTe7-MV3Opzrn_usXQA@mail.gmail.com |
| Views: | Whole Thread | Raw Message | Download mbox | Resend email |
| Thread: | |
| Lists: | pgsql-hackers |
On Sun, 23 Nov 2025, 11:28 Darafei "Komяpa" Praliaskouski,
<me(at)komzpa(dot)net> wrote:
>
> Other spots that may be invisible but helpful to keep track of are serialization/deserialization that happens on IN/OUT functions (so many surprises when EXPLAIN ANALYZE doesn't account for time to actually serialize the output for large PostGIS geometries! and that stuff like timestamptz in is also surprisingly slow),
Are you aware of the SERIALIZE option to EXPLAIN (...)? It was added
in PG 17 to make sure that the overhead of serializing the data for
transmission to a client could also be measured and inspected by the
user.
To keep on topic to this thread about wait events: I don't think that
we should add wait events around in/out functions, because in/out
functions may call into detoasting, which calls into buffer IO
functions, which would reset the backend's wait event status.
Kind regards,
Matthias van de Meent
Databricks (https://www.databricks.com)
| From | Date | Subject | |
|---|---|---|---|
| Next Message | Fabrice Chapuis | 2025-11-24 17:00:08 | Re: Issue with logical replication slot during switchover |
| Previous Message | Tom Lane | 2025-11-24 16:33:57 | Re: get rid of Pointer type, mostly |