Re: Zero throughput on a query on a very large table.

Поиск
Список
Период
Сортировка
От ldh@laurent-hasson.com
Тема Re: Zero throughput on a query on a very large table.
Дата
Msg-id BN6PR15MB118531B02818010CF1A26992859B0@BN6PR15MB1185.namprd15.prod.outlook.com
обсуждение исходный текст
Ответ на Re: Zero throughput on a query on a very large table.  (Tom Lane <tgl@sss.pgh.pa.us>)
Список pgsql-performance

Correct, but in the Java code, it's multiple statements in a single transaction, so it should stick. Not sure if something else stupid is going on.


Good to know about the ALTER DATABASE effect. I didn't realize that.


Thanks a billion.


Laurent.


From: Tom Lane <tgl@sss.pgh.pa.us>
Sent: Friday, January 25, 2019 3:04:37 PM
To: ldh@laurent-hasson.com
Cc: pgsql-performance@postgresql.org
Subject: Re: Zero throughput on a query on a very large table.
 
"ldh@laurent-hasson.com" <ldh@laurent-hasson.com> writes:
> Second, here is what i found and what messed us up.

>     select current_setting('random_page_cost'); --> 4
>     alter database "CMS_TMP" set random_page_cost=0.00000001;
>     select current_setting('random_page_cost'); --> 4 ????

ALTER DATABASE only affects subsequently-started sessions.

> I also tried:
>     select current_setting('random_page_cost'); --> 4
>     select set_config('random_page_cost', '0.000001', true);
>     select current_setting('random_page_cost'); --> 4 ????

That "true" means "local to the current transaction", which is
just the one statement if you don't have a BEGIN.

                        regards, tom lane

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

Предыдущее
От: Tom Lane
Дата:
Сообщение: Re: Zero throughput on a query on a very large table.
Следующее
От: Adrien NAYRAT
Дата:
Сообщение: Re: ERROR: found xmin from before relfrozenxid