From: | Kyotaro HORIGUCHI <horiguchi(dot)kyotaro(at)lab(dot)ntt(dot)co(dot)jp> |
---|---|
To: | robertmhaas(at)gmail(dot)com |
Cc: | tgl(at)sss(dot)pgh(dot)pa(dot)us, pgsql-hackers(at)postgresql(dot)org |
Subject: | Re: Get more from indices. |
Date: | 2013-11-11 09:29:47 |
Message-ID: | 20131111.182947.147160799.horiguchi.kyotaro@lab.ntt.co.jp |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-hackers |
Thank you,
> In any case, it seems like a bad idea to me to conflate
> distinct-ness with ordering, so I don't like what you did to
> PathKeys.
Hmm, that sounds quite resonable in general. But the conflation
is already found in grouping_planner to some extent. The name
distinct_pathkey itself asserts that it is the ordering used for
distinct. And actually is used for sorting if hashed-distinct is
not selected.
Plus, these modifications in grouping_planner is required by the
patch for pathkeys.c to be effective.
I suppose the main cause of nastiness of the patch for
grouping_planner comes from the adheration of the usage of the
variable for path uniqueness with the existent code.
The additional members to Plan, say, pathkeys and ordered could
help the code to look less ugly by taking in the related code
currently appears nakedly in grouping_planner into make(or
generate)_xxxxplan() functions. Although the new attributes
somewhat look out of place..
> > However, if the index is unique, wouldn't
> > scanning the index produce data that actually satisfies the longer sort
> > key? It doesn't matter what the values of c,d are if there are no
> > duplicates in the a,b columns. So maybe as a separate patch, we could
> > look at claiming that a unique index satisfies the entire query_pathkeys
> > if it matches the first N columns of that.
>
> That would be really spiffy.
# Putting aside the trueness of the assumption for unique-index
# and pathkeys.
The "expanded" sufficiency check can be archieved by involving
'unique-indexed' attribute for pathkeys_contained_in(),say
pathkeys_satisfies(pathkeys, pathkeys, is_uniq), but finally
could have no effect without some extent of assist in the process
in grouping_planner like my preveous patch to be in effect, I
believe.
I'll try to rewrite the path to be as following considering less
conflating lookings in grouping_planner.
- is_unique and pathkeys is added to the type Path. (umm...)
- create function like pathkeys_satisfies(check_pathkeys,
pathkeys, isuniq) or path_ordered_by(pathkeys, path) as
needed.
- Plan will be set ordered and pathkeys derived from source path
and its process and grouping_planner consults it to deceide
whether to do sort (to hide the currently naked code).
- Add check for NULLuble columns :-)
regards,
--
Kyotaro Horiguchi
NTT Open Source Software Center
From | Date | Subject | |
---|---|---|---|
Next Message | Kyotaro HORIGUCHI | 2013-11-11 09:30:59 | Re: Get more from indices. |
Previous Message | Boszormenyi Zoltan | 2013-11-11 09:17:54 | Re: ECPG FETCH readahead |