Re: [HACKERS] Re: Improve OR conditions on joined columns (commonstar schema problem)
От | Noah Misch |
---|---|
Тема | Re: [HACKERS] Re: Improve OR conditions on joined columns (commonstar schema problem) |
Дата | |
Msg-id | 20181002143941.GA219060@rfd.leadboat.com обсуждение исходный текст |
Ответ на | Re: [HACKERS] Re: Improve OR conditions on joined columns (common star schema problem) (Tom Lane <tgl@sss.pgh.pa.us>) |
Ответы |
Re: [HACKERS] Re: Improve OR conditions on joined columns (common star schema problem)
|
Список | pgsql-hackers |
On Mon, Oct 01, 2018 at 09:32:10PM -0400, Tom Lane wrote: > Michael Paquier <michael@paquier.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?
В списке pgsql-hackers по дате отправления: