Re: Table AM Interface Enhancements

Поиск
Список
Период
Сортировка
От Alexander Korotkov
Тема Re: Table AM Interface Enhancements
Дата
Msg-id CAPpHfdv2p3KvwakwPWmxynxHH6Ddq3LyK8LHPHeBS3tpxXqcUA@mail.gmail.com
обсуждение исходный текст
Ответ на Re: Table AM Interface Enhancements  (Andres Freund <andres@anarazel.de>)
Ответы Re: Table AM Interface Enhancements  (Pavel Borisov <pashkin.elfe@gmail.com>)
Re: Table AM Interface Enhancements  (Robert Haas <robertmhaas@gmail.com>)
Список pgsql-hackers
On Mon, Apr 15, 2024 at 11:17 PM Andres Freund <andres@anarazel.de> wrote:
> On 2024-04-15 16:02:00 -0400, Robert Haas wrote:
> > Do you want that patch applied, not applied, or applied with some set of
> > modifications?
>
> I think we should apply Alexander's proposed revert and then separately
> discuss what we should do about 041b96802ef.

Taking a closer look at acquire_sample_rows(), I think it would be
good if table AM implementation would care about block-level (or
whatever-level) sampling.  So that acquire_sample_rows() just fetches
tuples one-by-one from table AM implementation without any care about
blocks.  Possible table_beginscan_analyze() could take an argument of
target number of tuples, then those tuples are just fetches with
table_scan_analyze_next_tuple().  What do you think?

------
Regards,
Alexander Korotkov



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

Предыдущее
От: Richard Guo
Дата:
Сообщение: Re: [PATCH] Replace magic constant 3 with NUM_MERGE_MATCH_KINDS
Следующее
От: David Rowley
Дата:
Сообщение: Re: Add bump memory context type and use it for tuplesorts