Re: Refactoring IndexPath representation of index conditions

Hi,

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.

Andres