From: | Noah Misch <noah(at)leadboat(dot)com> |
---|---|
To: | Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us> |
Cc: | Michael Paquier <michael(at)paquier(dot)xyz>, Jim Nasby <jim(dot)nasby(at)openscg(dot)com>, pgsql-hackers(at)lists(dot)postgresql(dot)org |
Subject: | Re: [HACKERS] Re: Improve OR conditions on joined columns (common star schema problem) |
Date: | 2018-10-02 14:39:41 |
Message-ID: | 20181002143941.GA219060@rfd.leadboat.com |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-hackers |
On Mon, Oct 01, 2018 at 09:32:10PM -0400, Tom Lane wrote:
> Michael Paquier <michael(at)paquier(dot)xyz> writes:
> > On Mon, Sep 03, 2018 at 06:59:10PM -0700, Noah Misch wrote:
> >> If you're going to keep this highly-simplified estimate, please expand the
> >> comment to say why it doesn't matter or what makes it hard to do better. The
> >> non-planunionor.c path for the same query computes its own estimate of the
> >> same underlying quantity. Though it may be too difficult in today's system,
> >> one could copy the competing path's row count estimate here. Perhaps it
> >> doesn't matter because higher-level processing already assumes equal row count
> >> among competitors?
>
> > As there has been no replies to Noah's review for one month, I am
> > marking this patch as returned with feedback for now.
>
> FWIW, my problem with this patch is that I remain unconvinced of the basic
> correctness of the transform (specifically the unique-ification approach).
> Noah's points would be important to address if we were moving the patch
> towards commit, but I don't see much reason to put effort into it until
> we can think of a way to prove whether that works.
Not even effort to fix the assertion failures I reported?
From | Date | Subject | |
---|---|---|---|
Next Message | Andres Freund | 2018-10-02 14:49:01 | Re: transction_timestamp() inside of procedures |
Previous Message | KIRTIKA SINGHAL | 2018-10-02 14:22:07 | Regarding Google Code-In mentorship |