Re: why partition pruning doesn't work?
От | Dmitry Dolgov |
---|---|
Тема | Re: why partition pruning doesn't work? |
Дата | |
Msg-id | CA+q6zcVeHsvhqt+mZOax2njJe9cpoYAyfXNAYsRQ54ecJ+1gxw@mail.gmail.com обсуждение исходный текст |
Ответ на | Re: why partition pruning doesn't work? (Amit Langote <Langote_Amit_f8@lab.ntt.co.jp>) |
Ответы |
Re: why partition pruning doesn't work?
|
Список | pgsql-hackers |
> On 5 June 2018 at 12:31, Amit Langote <Langote_Amit_f8@lab.ntt.co.jp> wrote: > > doesn't look quite right. What says expr is really a Param? The patch > appears to work because, by setting pinfo->execparams to *something*, it > triggers execution-time pruning to run; its contents aren't necessarily > used during execution pruning. In fact, it would've crashed if the > execution-time pruning code had required execparams to contain *valid* > param id, but currently it doesn't. > > What I think we'd need to do to make this work is to make execution-time > pruning be invoked even if there aren't any Params involved. IOW, let's > try to teach make_partition_pruneinfo that it can go ahead also in the > cases where there are expressions being compared with the partition key > that contain (only) stable functions. Then, go and fix the > execution-pruning code to not *always* expect there to be Params to prune > with. Yeah, I agree - I copied this approach mindlessly from the original hacky patch. So, looks like it's necessary to have something like got_stable_expr together with gotparam. And after that the only place where I see Params are in use is partkey_datum_from_expr where all the stuff is actually evaluated. So apparently this part about "fix the execution-pruning code to not *always* expect there to be Params to prune with" will be only about this function - am I correct or there is something else that I missed?
В списке pgsql-hackers по дате отправления: