Hi Jian He, Thanks for fixing the compiler warnings, seems the CI used a little old compiler and complained:
ISO C90 forbids mixed declarations and code [-Werror=declaration-after-statement] But later C standard have relaxed the requirements for this, ISO C99 and later standard allow declarations and code to be freely mixed within compound statements: https://gcc.gnu.org/onlinedocs/gcc/Mixed-Labels-and-Declarations.html Mixed Labels and Declarations (Using the GNU Compiler Collection (GCC))<https://gcc.gnu.org/onlinedocs/gcc/Mixed-Labels-and-Declarations.html> Mixed Labels and Declarations (Using the GNU Compiler Collection (GCC)) gcc.gnu.org ________________________________ From: jian he <jian.universal...@gmail.com> Sent: Wednesday, September 6, 2023 14:00 To: Jian Guo <gj...@vmware.com> Cc: Tomas Vondra <tomas.von...@enterprisedb.com>; Hans Buschmann <buschm...@nidsa.net>; pgsql-hackers@lists.postgresql.org <pgsql-hackers@lists.postgresql.org> Subject: Re: Wrong rows estimations with joins of CTEs slows queries by more than factor 500 !! External Email On Tue, Aug 22, 2023 at 10:35 AM Jian Guo <gj...@vmware.com> wrote: > > Sure, Tomas. > > Here is the PG Commitfest link: > https://nam04.safelinks.protection.outlook.com/?url=https%3A%2F%2Fcommitfest.postgresql.org%2F44%2F4510%2F&data=05%7C01%7Cgjian%40vmware.com%7C711eddbb381e4e5ed2cb08dbae9ea0cf%7Cb39138ca3cee4b4aa4d6cd83d9dd62f0%7C0%7C0%7C638295768555223775%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C3000%7C%7C%7C&sdata=%2FuPl5rS1rFaQRnNevIVxKZCNA2Bbmr2rg%2BRoX5yUE9s%3D&reserved=0<https://commitfest.postgresql.org/44/4510/> > ________________________________ hi. wondering around https://nam04.safelinks.protection.outlook.com/?url=http%3A%2F%2Fcfbot.cputube.org%2F&data=05%7C01%7Cgjian%40vmware.com%7C711eddbb381e4e5ed2cb08dbae9ea0cf%7Cb39138ca3cee4b4aa4d6cd83d9dd62f0%7C0%7C0%7C638295768555223775%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C3000%7C%7C%7C&sdata=t%2B8JrNQQAibe3Hdeico06U3HhLx70B17kzPMERY39os%3D&reserved=0<http://cfbot.cputube.org/> there is a compiler warning: https://nam04.safelinks.protection.outlook.com/?url=https%3A%2F%2Fcirrus-ci.com%2Ftask%2F6052087599988736&data=05%7C01%7Cgjian%40vmware.com%7C711eddbb381e4e5ed2cb08dbae9ea0cf%7Cb39138ca3cee4b4aa4d6cd83d9dd62f0%7C0%7C0%7C638295768555223775%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C3000%7C%7C%7C&sdata=8WbXadRi7MhO0AiHjtJOs4y5mqCP8VHBdcQao%2FXPpM8%3D&reserved=0<https://cirrus-ci.com/task/6052087599988736> I slightly edited the code, making the compiler warning out. I am not sure if the following duplicate comment from (rte->rtekind == RTE_SUBQUERY && !rte->inh) branch is correct. /* * OK, recurse into the subquery. Note that the original setting * of vardata->isunique (which will surely be false) is left * unchanged in this situation. That's what we want, since even * if the underlying column is unique, the subquery may have * joined to other tables in a way that creates duplicates. */ Index varnoSaved = var->varno; here varnoSaved should be int? image attached is the coverage report if I understand coverage report correctly, ` if (rel->subroot) examine_simple_variable(rel->subroot, var, vardata); ` the above never actually executed? !! External Email: This email originated from outside of the organization. Do not click links or open attachments unless you recognize the sender.
