| From: | Wolfgang Walther <walther(at)technowledgy(dot)de> |
|---|---|
| To: | Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us>, "David G(dot) Johnston" <david(dot)g(dot)johnston(at)gmail(dot)com> |
| Cc: | Laurenz Albe <laurenz(dot)albe(at)cybertec(dot)at>, Olleg Samoylov <splarv(at)ya(dot)ru>, "pgsql-generallists(dot)postgresql(dot)org" <pgsql-general(at)lists(dot)postgresql(dot)org> |
| Subject: | Re: Interesting case of IMMUTABLE significantly hurting performance |
| Date: | 2025-04-14 10:18:44 |
| Message-ID: | 4ea0957f-d599-47e5-ae9e-758ec6711e03@technowledgy.de |
| Views: | Raw Message | Whole Thread | Download mbox | Resend email |
| Thread: | |
| Lists: | pgsql-general |
Tom Lane:
> If you err in the other direction, you don't get slapped on the
> wrist that way. We're willing to inline VOLATILE functions,
> for instance, whether or not the contained expression is volatile.
> Similarly for STRICT, and I think parallel safety as well.
> So my own habit when writing a SQL function that I wish to be
> inlined is to leave off all those markings.
According to [1], this only applies to inlining of scalar functions, but
not to table functions, which *need* to be either STABLE or IMMUTABLE.
Just mentioning this for anyone taking this advice blindly and leaving
all marks off, which might not always work as expected in the general case.
Best,
Wolfgang
[1]: https://wiki.postgresql.org/wiki/Inlining_of_SQL_functions
| From | Date | Subject | |
|---|---|---|---|
| Next Message | Dimitrios Apostolou | 2025-04-14 10:57:04 | TRUNCATE ONLY with foreign keys and triggers disabled |
| Previous Message | Wolfgang Walther | 2025-04-14 10:09:47 | Re: Event-Triggers for DB owners instead of just SUPERUSER |