From: | "Etsuro Fujita" <fujita(dot)etsuro(at)lab(dot)ntt(dot)co(dot)jp> |
---|---|
To: | "'Kyotaro HORIGUCHI'" <horiguchi(dot)kyotaro(at)lab(dot)ntt(dot)co(dot)jp> |
Cc: | <pgsql-hackers(at)postgresql(dot)org>, <tgl(at)sss(dot)pgh(dot)pa(dot)us>, <robertmhaas(at)gmail(dot)com> |
Subject: | Re: Get more from indices. |
Date: | 2013-12-05 11:48:19 |
Message-ID: | 00ad01cef1af$e44793b0$acd6bb10$@etsuro@lab.ntt.co.jp |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-hackers |
Kyotaro HORIGUCHI wrote:
> Thank you, but it seems to me too simplified. You made two major
functional
> changes.
Thank you for the comments!
> One is, you put the added code for getrelation_info() out of the block for
> the condition (info->relam == BTREE_AM_OID) (though amcanorder would be
> preferable..) Anyway the reason for the place is to guarantee
'full_ordered'
> index always to be orderable. I believe the relation between them are not
> obvious. So your patch has an oppotunity to make wrong assumption for
> possible indexes which is not orderable but unique. Going on your way some
> additional works would be needed to judge an index to be orderable or not
> on checking the extensibility of pathkeys.
By checking the following equation in build_index_paths(), the updated
version of the patch guarantees that the result of an index scan is ordered:
index_is_ordered = (index->sortopfamily != NULL);
> Another is, you changed pathkeys expantion to be all-or-nothing decision.
> While this change should simplify the code slightly, it also dismisses the
> oppotunity for partially-extended pathkeys. Could you let me know the
reason
> why you did so.
At first I thought the partially-extended pathkey list that is made from
query_pathkeys, as you proposed in the original versions of the patch. But
I've started to doubt whether it's worth doing that because I think the
partially-extended pathkey list is merely one example while the original
pathkey list can be partially-extended in different ways, ie, ISTM the
partially-extended pathkey list doesn't necessarily have the optimality in
anything significant. We might be able to partially-extend the original
pathkey list optimally in something significant, but that seems useless
complexity to me. So, I modified the patch to do the all-or-nothing
decision.
Thanks,
Best regards,
Etsuro Fujita
From | Date | Subject | |
---|---|---|---|
Next Message | Etsuro Fujita | 2013-12-05 12:05:10 | Re: Get more from indices. |
Previous Message | Andres Freund | 2013-12-05 11:39:38 | Re: better atomics - v0.2 |