Re: Index Skip Scan

Поиск
Список
Период
Сортировка
От Jesper Pedersen
Тема Re: Index Skip Scan
Дата
Msg-id c9b12a76-5b95-a29d-9d02-cac74ab40253@redhat.com
обсуждение исходный текст
Ответ на Re: Index Skip Scan  (Thomas Munro <thomas.munro@gmail.com>)
Список pgsql-hackers
Hi,

On 7/9/19 10:14 PM, Thomas Munro wrote:
>> Thomas, do you have any ideas for this ? I can see that MySQL did the
>> functionality in two change sets (base and function support), but like
>> you said we shouldn't paint ourselves into a corner.
> 
> I think amskip() could be augmented by later patches to take a
> parameter 'skip mode' that can take values SKIP_FIRST, SKIP_LAST and
> SKIP_FIRST | SKIP_LAST (meaning please give me both).  What we have in
> the current patch is SKIP_FIRST behaviour.  Being able to choose
> SKIP_FIRST or SKIP_LAST allows you do handle i, MAX(j) GROUP BY (i)
> ORDER BY i (ie forward scan for the order, but wanting the highest key
> for each distinct prefix), and being able to choose both allows for i,
> MIN(j), MAX(j) GROUP BY i.  Earlier I thought that this scheme that
> allows you to ask for both might be incompatible with David's
> suggestion of tracking UniqueKeys in paths, but now I see that it
> isn't: it's just that SKIP_FIRST | SKIP_LAST would have no UniqueKeys
> and therefore require a regular agg on top.  I suspect that's OK: this
> min/max transformation stuff is highly specialised and can have
> whatever magic path-building logic is required in
> preprocess_minmax_aggregates().
> 

Ok, great.

Thanks for your feedback !

Best regards,
  Jesper



В списке pgsql-hackers по дате отправления:

Предыдущее
От: Melanie Plageman
Дата:
Сообщение: Re: PGOPTIONS="-fh" make check gets stuck since Postgres 11
Следующее
От: Robert Haas
Дата:
Сообщение: Re: let's make the list of reportable GUCs configurable (was Re: Add%r substitution for psql prompts to show recovery status)