Re: analyze-in-stages post upgrade questions

On Sat, 2025-06-28 at 01:23 +, Zechman, Derek S wrote: > > Well, that wouldn't explain why it doesn't work on partitioned tables. > > I am under the impression that it should. > > > > Derek, can cou share the pg_stats entries for the partitioned table? > > There are no entries in pg_stats for

RE: analyze-in-stages post upgrade questions

> > We recently performed an upgrade from pg14 (14.18) to pg16 (16.9) and > > performed the analyze-in-stages post upgrade. It has been noticed that > > some plans changed to use hash joins instead of nested loops. Further > > investigation found it was because the parent table of partitioned

RE: analyze-in-stages post upgrade questions

We recently performed an upgrade from pg14 (14.18) to pg16 (16.9) and performed the analyze-in-stages post upgrade. It has been noticed that some plans changed to use hash joins instead of nested loops. Further investigation found it was because the parent table of partitioned tables did no

Re: analyze-in-stages post upgrade questions

On Fri, 2025-06-27 at 08:31 -0700, Adrian Klaver wrote: > On 6/27/25 06:35, Zechman, Derek S wrote: > > We recently performed an upgrade from pg14 (14.18) to pg16 (16.9) and > > performed the analyze-in-stages post upgrade.  It has been noticed that > > some plans changed to use hash joins instea

Re: password rules

Am 26.06.2025 um 14:27 schrieb Peter J. Holzer: On 2025-06-25 17:55:12 +0200, raphi wrote: Am 25.06.2025 um 17:33 schrieb Peter J. Holzer: On 2025-06-25 14:42:26 +0200, raphi wrote: That's not how the identiy principle works, at least not how it's implement in our company. A user in ldap ha

Re: analyze-in-stages post upgrade questions

On 6/27/25 06:35, Zechman, Derek S wrote: We recently performed an upgrade from pg14 (14.18) to pg16 (16.9) and performed the analyze-in-stages post upgrade.  It has been noticed that some plans changed to use hash joins instead of nested loops.  Further investigation found it was because the p

Re: Figure out nullability of query parameters

> > It would be really handy to know that `$1` is being used as a non nullable > value To push back in a different way, how exactly would this be useful? The system catalogs are the best place to get all the various information about a relation, including any and all constraints. Data type info

Re: Figure out nullability of query parameters

On Friday, June 27, 2025, Giacomo Cavalieri wrote: > > It would be really handy to know that `$1` is being used as a non nullable > value, while `$2` could actually be null. Can this already be achieve > today, or would there be a way to surface this kind of information for > query parameters in

Re: Figure out nullability of query parameters

Hi, I have no idea how/if this is possible using the query protocol but I would try to parse the INSERT statement to get the table and columns names and then look up whether they are nullable in the information schema ( https://www.postgresql.org/docs/current/infoschema-columns.html) Petr On Fri,

Figure out nullability of query parameters

Hello! I’m Giacomo, I’m the maintainer of , a tool that can generate type safe bindings to run and decode the results of Postgres queries. It does that by implementing the extended query protocol, which, among other things, returns the OIDs of the q

Re: analyze-in-stages post upgrade questions

On Fri, Jun 27, 2025 at 9:35 AM Zechman, Derek S wrote: > > > We recently performed an upgrade from pg14 (14.18) to pg16 (16.9) and > performed the analyze-in-stages post upgrade. It has been noticed that > some plans changed to use hash joins instead of nested loops. Further > investigation fo

analyze-in-stages post upgrade questions

We recently performed an upgrade from pg14 (14.18) to pg16 (16.9) and performed the analyze-in-stages post upgrade. It has been noticed that some plans changed to use hash joins instead of nested loops. Further investigation found it was because the parent table of partitioned tables did not