Date: Mon, 6 Apr 2020 18:39:41 +0200
From: Dmitry Dolgov <9erthalion6@gmail.com>
To: Dilip Kumar <dilipbalaut@gmail.com>
Cc: Floris Van Nee <florisvannee@optiver.com>,
	David Rowley <dgrowleyml@gmail.com>,
	Kyotaro Horiguchi <horikyota.ntt@gmail.com>,
	Tomas Vondra <tomas.vondra@2ndquadrant.com>,
	Peter Geoghegan <pg@bowt.ie>,
	Jesper Pedersen <jesper.pedersen@redhat.com>,
	Alvaro Herrera <alvherre@2ndquadrant.com>,
	Thomas Munro <thomas.munro@gmail.com>,
	James Coleman <jtc331@gmail.com>,
	Rafia Sabih <rafia.pghackers@gmail.com>,
	Jeff Janes <jeff.janes@gmail.com>,
	"bhushan.uparkar@gmail.com" <bhushan.uparkar@gmail.com>,
	PostgreSQL-development <pgsql-hackers@postgresql.org>,
	Alexander Korotkov <a.korotkov@postgrespro.ru>
Subject: Re: Index Skip Scan
Message-ID: <20200406163941.rh3okji2rhbnptyt@localhost>
References: <20200310123942.nse4uyd6yqtb7uyi@localhost>
 <CAApHDvo1NF0Qv9ZdnuDu03=1JwEq7GiVa-q3Qu=aMzmD9SV-vQ@mail.gmail.com>
 <20200324163919.7nwqe72xzfatix4y@localhost>
 <CAFiTN-ujFt8g801vYnpoveCWsm0ExjYdjkewGasOQxiH0hmjzQ@mail.gmail.com>
 <20200325085100.5fixaiteuoln4f45@localhost>
 <CAFiTN-sgsxS7cXi0sd9UWmbSwjPc6+78rGa4SFfAxGfs5zj7Aw@mail.gmail.com>
 <20200405161029.fpqqll7xbgfqy5na@localhost>
 <CAFiTN-sRnYp7MkctzYakyjWRPQQHFzEAwKV8vwf+sUgA+8JtQw@mail.gmail.com>
 <80ef5f0744f542b18e508fb589a6425a@opammb0562.comp.optiver.com>
 <CAFiTN-tp8S3BTwYXT33tnY=53fNCsS4ZZUjbEFtcJym1acoLeA@mail.gmail.com>
MIME-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Content-Disposition: inline
In-Reply-To: 
 <CAFiTN-tp8S3BTwYXT33tnY=53fNCsS4ZZUjbEFtcJym1acoLeA@mail.gmail.com>
Precedence: bulk

> On Mon, Apr 6, 2020 at 1:14 PM Floris Van Nee <florisvannee@optiver.com> wrote:
> >
> > There's a number of ways we can force a 'filter' rather than an
> > 'index condition'.

Hm, I wasn't aware about this one, thanks for bringing this up. Btw,
Floris, I would appreciate if in the future you can make it more visible
that changes you suggest contain some fixes. E.g. it wasn't clear for me
from your previous email that that's the case, and it doesn't make sense
to pull into different direction when we're trying to achieve the same
goal :)

> > In the patch I posted a week ago these cases are all handled
> > correctly, as it introduces this extra logic in the Executor.
>
> Okay, So I think we can merge those fixes in Dmitry's patch set.

I'll definitely take a look at suggested changes in filtering part.