Re: inconsistent results querying table partitioned by date
От | David Rowley |
---|---|
Тема | Re: inconsistent results querying table partitioned by date |
Дата | |
Msg-id | CAKJS1f82n-WNsu6G5WNXGFV4MsnosydiouRvTNnZYmQz0tciuQ@mail.gmail.com обсуждение исходный текст |
Ответ на | Re: inconsistent results querying table partitioned by date (Tom Lane <tgl@sss.pgh.pa.us>) |
Ответы |
Re: inconsistent results querying table partitioned by date
Re: inconsistent results querying table partitioned by date |
Список | pgsql-bugs |
On Wed, 15 May 2019 at 08:58, Tom Lane <tgl@sss.pgh.pa.us> wrote: > So I think David's got the right idea that match_clause_to_partition_key > is where to handle this, and I like the fact that his patch explicitly > represents whether we're trying to do run-time or plan-time pruning. > I agree it's kind of invasive, and I wonder why. Shouldn't the > additional flag just be a field in the "context" struct, instead of > being a separate parameter that has to be laboriously passed through > many call levels? Thanks for having a look. I originally stayed clear of "context" since it looks more like how we output the pruning steps, rather than a context as to how they should be generated. But it's true, using it saves having to pass the extra argument around, so I made that change. > (For myself, I'd have made it just a bool not an enum, given that > I don't foresee a need for additional values. But that's definitely > a matter of preference.) I've changed to bool, mostly because it makes the patch a bit smaller. > Also, I'm a bit confused by the fact that we seem to have a bunch > of spare-parts patches in this thread. What combination is actually > being proposed for commit? I was also confused at the extra two patches Amit posted. The extra one for the tests didn't look very valid to me, as I mentioned yesterday. I propose the attached for master, and I'll post something for v11 shortly. -- David Rowley http://www.2ndQuadrant.com/ PostgreSQL Development, 24x7 Support, Training & Services
Вложения
В списке pgsql-bugs по дате отправления: