Re: Binary search in ScalarArrayOpExpr for OR'd constant arrays

Поиск
Список
Период
Сортировка
От David Rowley
Тема Re: Binary search in ScalarArrayOpExpr for OR'd constant arrays
Дата
Msg-id CAApHDvrxEm00=8fDdrbGtUm-Z6NqDfvDz6Ss3U3VSzTxwM6NbA@mail.gmail.com
обсуждение исходный текст
Ответ на Re: Binary search in ScalarArrayOpExpr for OR'd constant arrays  (David Rowley <dgrowleyml@gmail.com>)
Ответы Re: Binary search in ScalarArrayOpExpr for OR'd constant arrays
Список pgsql-hackers
On Thu, 8 Apr 2021 at 18:50, David Rowley <dgrowleyml@gmail.com> wrote:
> I've not done any further performance tests yet but will start those now.

I ran a set of tests on this:

select * from a where a in( < 1 to 10 > );
and
select * from a where a in( < 1 to 100 > );

the table "a" is just an empty table with a single int column.

I ran "pgbench -T 15 -c 16 -t 16" ten times each and the resulting tps
is averaged over the 10 runs.

With 10 items in the IN clause:
master: 99887.9098314 tps
patched: 103235.7616416 tps (3.35% faster)

With 100 items:
master: 62442.4838792 tps
patched:62275.4955754 tps (0.27% slower)

These tests are just designed to test the overhead of the additional
planning and expression initialisation.  Testing the actual
performance of the patch vs master with large IN lists shows the
expected significant speedups.

These results show that there's not much in the way of a measurable
slowdown in planning or executor startup from the additional code
which decides if we should hash the ScalarArrayOpExpr.

I think the changes in the patch are fairly isolated and the test
coverage is now pretty good.  I'm planning on looking at the patch
again now and will consider pushing it for PG14.

David



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

Предыдущее
От: David Rowley
Дата:
Сообщение: Re: Wired if-statement in gen_partprune_steps_internal
Следующее
От: Michael Paquier
Дата:
Сообщение: Re: DETAIL for wrong scram password