Re: Wrong results from Parallel Hash Full Join

Поиск
Список
Период
Сортировка
От Andres Freund
Тема Re: Wrong results from Parallel Hash Full Join
Дата
Msg-id 20230419192051.xkgyj76akczpbjbs@awork3.anarazel.de
обсуждение исходный текст
Ответ на Re: Wrong results from Parallel Hash Full Join  (Justin Pryzby <pryzby@telsasoft.com>)
Ответы Re: Wrong results from Parallel Hash Full Join  (Justin Pryzby <pryzby@telsasoft.com>)
Re: Wrong results from Parallel Hash Full Join  (Melanie Plageman <melanieplageman@gmail.com>)
Список pgsql-hackers
Hi,

On 2023-04-19 12:16:24 -0500, Justin Pryzby wrote:
> On Wed, Apr 19, 2023 at 11:17:04AM -0400, Melanie Plageman wrote:
> > Ultimately this is probably fine. If we wanted to modify one of the
> > existing tests to cover the multi-batch case, changing the select
> > count(*) to a select * would do the trick. I imagine we wouldn't want to
> > do this because of the excessive output this would produce. I wondered
> > if there was a pattern in the tests for getting around this.
> 
> You could use explain (ANALYZE).  But the output is machine-dependant in
> various ways (which is why the tests use "explain analyze so rarely).

I think with sufficient options it's not machine specific. We have a bunch of
 EXPLAIN (ANALYZE, COSTS OFF, SUMMARY OFF, TIMING OFF) ..
in our tests.

Greetings,

Andres Freund



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

Предыдущее
От: Tom Lane
Дата:
Сообщение: ExecAggTransReparent is underdocumented and badly named
Следующее
От: Melanie Plageman
Дата:
Сообщение: Re: Should we put command options in alphabetical order in the doc?