Tomas Vondra wrote:
> On 11/02/2018 08:16 AM, Antonin Houska wrote:
> > Tomas Vondra wrote:
> >
> >> OK, so the reason is that when building child paths, we don't keep
> >> the pathkeys unless it matches the "interesting" pathkeys.
> >>
> >> So for example we may have an IndexPath, but with pat
On 11/02/2018 08:16 AM, Antonin Houska wrote:
> Tomas Vondra wrote:
>
>> OK, so the reason is that when building child paths, we don't keep
>> the pathkeys unless it matches the "interesting" pathkeys.
>>
>> So for example we may have an IndexPath, but with pathkeys=NIL if
>> the index does not m
Tomas Vondra wrote:
> OK, so the reason is that when building child paths, we don't keep the
> pathkeys unless it matches the "interesting" pathkeys.
>
> So for example we may have an IndexPath, but with pathkeys=NIL if the
> index does not match the ORDER BY we need.
I don't agree that IndexPa
On 11/01/2018 08:51 PM, Antonin Houska wrote:
> Tomas Vondra wrote:
>
>> On 11/01/2018 12:48 PM, Antonin Houska wrote:
>>> Review of [1] made me think of this optimization, currently used only in
>>> create_merge_append_path():
>>>
>>> /*
>>> * Apply query-wide LIMIT if known and path
Tomas Vondra wrote:
> On 11/01/2018 12:48 PM, Antonin Houska wrote:
> > Review of [1] made me think of this optimization, currently used only in
> > create_merge_append_path():
> >
> > /*
> > * Apply query-wide LIMIT if known and path is for sole base relation.
> > * (Handling this
On 11/01/2018 08:11 PM, Tomas Vondra wrote:
> On 11/01/2018 12:48 PM, Antonin Houska wrote:
>> Review of [1] made me think of this optimization, currently used only in
>> create_merge_append_path():
>>
>> /*
>> * Apply query-wide LIMIT if known and path is for sole base relation.
>>
On 11/01/2018 12:48 PM, Antonin Houska wrote:
> Review of [1] made me think of this optimization, currently used only in
> create_merge_append_path():
>
> /*
>* Apply query-wide LIMIT if known and path is for sole base relation.
>* (Handling this at this low level is a bit kl
