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 по дате отправления: