From: | Brian Crowell <brian(at)fluggo(dot)com> |
---|---|
To: | Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us> |
Cc: | "pgsql-general(at)postgresql(dot)org >> PG-General Mailing List" <pgsql-general(at)postgresql(dot)org> |
Subject: | Re: PG choosing nested loop for set membership? |
Date: | 2014-03-26 16:54:55 |
Message-ID: | CAAQkdDrytBz6vSJRxBCvuVckdqwHE7LqgqTRHoXGeTTtgSPJGQ@mail.gmail.com |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-general |
On Wed, Mar 26, 2014 at 11:43 AM, Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us> wrote:
> In principle I guess we could somehow merge the stats of y and z
> when looking at a "coalesce(y, z)" expression, but I'm not sure
> how that would work exactly.
Yeah, I'm not sure there's anything to fix here, either. Just a
reminder that coalesces in joins are bad.
The only thing I could think was making an exception for the case when
all inputs to coalesce() have one row. I think that's what's happening
here; coalesce selectivity is estimated at less than one, even though
you can't get a cardinality any less than the inputs (they're already
one), so the nested loop sees an estimate that's less than the product
of its inputs. Or that's my guess anyhow.
Thanks for having a look!
--Brian
From | Date | Subject | |
---|---|---|---|
Next Message | Tim Spencer | 2014-03-26 19:17:54 | Re: Disk Encryption in Production |
Previous Message | Steven Schlansker | 2014-03-26 16:44:05 | Re: Trimming transaction logs after extended WAL archive failures |