Re: COALESCE patch - Mailing list pgsql-hackers

From Laurenz Albe
Subject Re: COALESCE patch
Date
Msg-id 2a99ac998e6e90df32efbe6c872c3665f447da23.camel@cybertec.at
Whole thread
In response to Re: COALESCE patch  (prankware <esavelievcode@gmail.com>)
List pgsql-hackers
On Fri, 2026-07-10 at 15:54 +0300, prankware wrote:
> Thanks for the review — the test cases were very helpful.
> You're right that v1 didn't improve the coalesce(col, const) case. The
> reason is that a comparison of two constants got the default 0.005
> instead of its real result, and joins with a constant on both sides
> were skipped entirely.
> v2 (attached) fixes both, and these four examples now estimate close
> to the actual row counts.

This version works fine.

It passes the regression tests.  It adds none of its own, but I
can't think of a good way to have stable regression tests for
anything that depends on optimizer statistics.

My biggest criticism at this point is the readability of the
code.  The function comments are alright, but try_coalesce_eq()
is tricky and could do with some comments that explain what is
going on and what the invariants are.

- Why is there a special treatment of a CoalesceExpr that
  match_coalesce_join_side() rejected?

- Why is it fine to assign a "bool" to a floating point variable?
  (An explicit type cast might be a good idea too.)

There are more places that could do with some illumination.

Also, why do you explicitly check for CoalesceExpr with less than
two arguments in match_coalesce_join_side()?

Yours,
Laurenz Albe



pgsql-hackers by date:

Previous
From: Tomas Vondra
Date:
Subject: Re: PGLZ Compression Optimization
Next
From: Andrew Dunstan
Date:
Subject: Re: Allow table AMs to define their own reloptions