Re: Support tid range scan in parallel?

Поиск
Список
Период
Сортировка
От David Rowley
Тема Re: Support tid range scan in parallel?
Дата
Msg-id CAApHDvqowkw1bdmERrX8KrKo0FNuhkx9fpZKRSnX7OUUN7Z5Zg@mail.gmail.com
обсуждение исходный текст
Ответ на Re: Support tid range scan in parallel?  (Cary Huang <cary.huang@highgo.ca>)
Ответы Re: Support tid range scan in parallel?
Список pgsql-hackers
On Fri, 10 May 2024 at 05:16, Cary Huang <cary.huang@highgo.ca> wrote:
> I understand that the regression tests for parallel ctid range scan is a
> bit lacking now. It only has a few EXPLAIN clauses to ensure parallel
> workers are used when tid ranges are specified. They are added as
> part of select_parallel.sql test. I am not sure if it is more appropriate
> to have them as part of tidrangescan.sql test instead. So basically
> re-run the same test cases in tidrangescan.sql but in parallel?

I think tidrangescan.sql is a more suitable location than
select_parallel.sql I don't think you need to repeat all the tests as
many of them are testing the tid qual processing which is the same
code as it is in the parallel version.

You should add a test that creates a table with a very low fillfactor,
low enough so only 1 tuple can fit on each page and insert a few dozen
tuples. The test would do SELECT COUNT(*) to ensure you find the
correct subset of tuples. You'd maybe want MIN(ctid) and MAX(ctid) in
there too for extra coverage to ensure that the correct tuples are
being counted.  Just make sure and EXPLAIN (COSTS OFF) the query first
in the test to ensure that it's always testing the plan you're
expecting to test.

David



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

Предыдущее
От: David Rowley
Дата:
Сообщение: Re: Use generation memory context for tuplestore.c
Следующее
От: Mark Dilger
Дата:
Сообщение: Re: [PATCH] Improve amcheck to also check UNIQUE constraint in btree index.