Date: Tue, 10 Mar 2020 13:39:42 +0100
From: Dmitry Dolgov <9erthalion6@gmail.com>
To: David Rowley <dgrowleyml@gmail.com>
Cc: Kyotaro Horiguchi <horikyota.ntt@gmail.com>,
	Tomas Vondra <tomas.vondra@2ndquadrant.com>,
	florisvannee@optiver.com, pg@bowt.ie, jesper.pedersen@redhat.com,
	Alvaro Herrera <alvherre@2ndquadrant.com>, thomas.munro@gmail.com,
	jtc331@gmail.com, rafia.pghackers@gmail.com,
	Jeff Janes <jeff.janes@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: <20200310123942.nse4uyd6yqtb7uyi@localhost>
References: <20200207162543.zlj2tvcwy7jku6vu@localhost>
 <20200208131159.5sjcbcjnwdj4q7fa@development>
 <20200214.172313.259958375378013155.horikyota.ntt@gmail.com>
 <20200214121820.xvvrkdbykkygfs65@localhost>
 <20200217162451.nrpy5k63f5y2mwm6@localhost>
 <CAApHDvo2abVQOiZ6wf9ExhobvvhLGWZQha0uWRAMby1NOD1ccw@mail.gmail.com>
 <20200308142228.3zb237cd3oedspl2@localhost>
 <CAApHDvrMRHm3BoW0ZHHAmZY91HVSSkhv1zKSPfQF0QfkN7NdpQ@mail.gmail.com>
 <20200309195714.eum3b6e5mogqj3gm@localhost>
 <CAApHDvqt22FonTKv6Ek61_kjTro+9KON1G18o9jC6svec2QaDg@mail.gmail.com>
MIME-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Content-Disposition: inline
In-Reply-To: 
 <CAApHDvqt22FonTKv6Ek61_kjTro+9KON1G18o9jC6svec2QaDg@mail.gmail.com>
Precedence: bulk

> >On Tue, Mar 10, 2020 at 09:29:32AM +1300, David Rowley wrote:
> On Tue, 10 Mar 2020 at 08:56, Dmitry Dolgov <9erthalion6@gmail.com> wrote:
> > Assuming we'll implement it in a way that we do not know about what kind
> > of path type is that in create_distinct_path, then it can also work for
> > ProjectionPath or anything else (if UniqueKeys are present). But then
> > still EquivalenceMember are used only to figure out correct
> > distinctPrefixKeys and do not affect whether or not skipping is applied.
> > What do I miss?
>
> I'm not sure I fully understand the question correctly, but let me
> explain further.
>
> In the 0001 patch, standard_qp_callback sets the query_uniquekeys
> depending on the DISTINCT / GROUP BY clause.  When building index
> paths in build_index_paths(), the 0002 patch should be looking at the
> root->query_uniquekeys to see if it can build any index paths that
> suit those keys.  Such paths should be tagged with the uniquekeys they
> satisfy, basically, exactly the same as how pathkeys work.  Many
> create_*_path functions will need to be modified to carry forward
> their uniquekeys. For example, create_projection_path(),
> create_limit_path() don't do anything which would cause the created
> path to violate the unique keys.   This way when you get down to
> create_distinct_paths(), paths other than IndexPath may have
> uniquekeys.  You'll be able to check which existing paths satisfy the
> unique keys required by the DISTINCT / GROUP BY and select those paths
> instead of having to create any HashAggregate / Unique paths.
>
> Does that answer the question?

Hmm... I'm afraid no, this was already clear. But looks like now I see
that I've misinterpreted one part.

> There's also some weird looking assumptions that an EquivalenceMember
> can only be a Var in create_distinct_paths(). I think you're only
> saved from crashing there because a ProjectionPath will be created
> atop of the IndexPath to evaluate expressions, in which case you're
> not seeing the IndexPath.  This results in the optimisation not
> working in cases like:

I've read it as "an assumption that an EquivalenceMember can only be a
Var" results in "the optimisation not working in cases like this". But
you've meant that ignoring a ProjectionPath with an IndexPath inside
results in this optimisation not working, right? If so, then everything
is clear, and my apologies, maybe I need to finally fix my sleep
schedule :)