|From:||Andres Freund <andres(at)anarazel(dot)de>|
|To:||Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us>|
|Subject:||Re: Refactoring IndexPath representation of index conditions|
|Views:||Raw Message | Whole Thread | Download mbox | Resend email|
On 2019-02-02 11:29:10 -0500, Tom Lane wrote:
> I think that the original idea here was that we should do as little
> work as possible "up front", since most index paths will get discarded
> before we reach createplan.c. But to the extent that that was valid
> at all, it's gotten overtaken by circumstances. In particular,
> postponing work to expand_indexqual_conditions (which is called by
> create_index_path) is just stupid, because these days we typically
> call that several times with the same index conditions. It's really
> dubious that postponing commutation to createplan.c is a net win either,
It seems your approach isn't particularly in contradiction to the
stated historical goal. We could create the new struct, but just not
populate it eagerly, right?
> Thoughts? If there's not objections I'd like to push this soon.
Seems reasonable from a very very quick skim.
|Next Message||Andrew Gierth||2019-02-02 20:14:18||Re: Ryu floating point output patch|
|Previous Message||Tom Lane||2019-02-02 19:01:01||Re: Early WIP/PoC for inlining CTEs|