Alvaro Herrera writes:
> On 2019-Feb-02, Tom Lane wrote:
>> Another idea that I looked into is to not create RestrictInfos for
>> derived indexqual clauses, with the hope that that would further
>> reduce the added overhead for the commuted-clause case. However
>> that crashed and burned when I f
On 2019-Feb-02, Tom Lane wrote:
> In any case I think it makes things simpler and clearer, which is
> worth a good deal.
Looking at the patch, I agree -- this is clearer than what was there
before.
> Another idea that I looked into is to not create RestrictInfos for
> derived indexqual clauses,
Andres Freund writes:
> 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,
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
I've been poking at the problem discussed in a couple of recent threads
of letting extensions in on the ability to create "lossy index conditions"
for complex operators/functions. The current design for that in
indxpath.c is frankly just a pile of kluges of varying ages. In the
initial pass, the
