Re: Wired if-statement in gen_partprune_steps_internal

From: David Rowley <dgrowleyml(at)gmail(dot)com>
To: Amit Langote <amitlangote09(at)gmail(dot)com>
Cc: Andy Fan <zhihui(dot)fan1213(at)gmail(dot)com>, PostgreSQL Hackers <pgsql-hackers(at)lists(dot)postgresql(dot)org>
Subject: Re: Wired if-statement in gen_partprune_steps_internal
Date: 2021-04-07 11:44:38
Message-ID: CAApHDvp=4GpbPVJuFnx-5p8e2BU_9P6yTA2p3Cg78RD6tJs6GQ@mail.gmail.com
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-hackers

On Wed, 7 Apr 2021 at 21:53, David Rowley <dgrowleyml(at)gmail(dot)com> wrote:
> If canonicalize_qual() had been unable to rewrite that WHERE clause
> then I could see that we might want to combine steps from other
> recursive quals. I'm thinking right now that I'm glad
> canonicalize_qual() does that hard work for us. (I think partprune.c
> could handle the original WHERE clause as-is in this example
> anyway...)

I made a pass over the v2 patch and since it's been a long time since
I'd looked at partprune.c I ended doing further rewriting of the
comments you'd changed.

There's only one small code change as I didn't like the following:

- return result;
+ /* A single step or no pruning possible with the provided clauses. */
+ return steps ? linitial(steps) : NULL;

I ended up breaking that out into an if condition.

All the other changes are around the comments.

Can you look over this and let me know if you're happy with the changes?

David

Attachment Content-Type Size
v3-0001-Cosmetic-improvements-to-partition-pruning-step-g.patch application/octet-stream 18.0 KB

In response to

Responses

Browse pgsql-hackers by date

  From Date Subject
Next Message Andrew Dunstan 2021-04-07 11:49:38 Re: buildfarm instance bichir stuck
Previous Message Andrey Borodin 2021-04-07 11:44:32 Re: MultiXact\SLRU buffers configuration