Re: Refactoring IndexPath representation of index conditions

From: Andres Freund <andres(at)anarazel(dot)de>
To: Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us>
Cc: pgsql-hackers(at)lists(dot)postgresql(dot)org
Subject: Re: Refactoring IndexPath representation of index conditions
Date: 2019-02-02 20:02:32
Views: Raw Message | Whole Thread | Download mbox | Resend email
Lists: pgsql-hackers


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.


In response to


Browse pgsql-hackers by date

  From Date Subject
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