Re: problem with from_collapse_limit and joined views

От: Markus Schulz
Тема: Re: problem with from_collapse_limit and joined views
Дата: ,
Msg-id: 201012041920.29616@Mail-Followup-To
(см: обсуждение, исходный текст)
Ответ на: Re: problem with from_collapse_limit and joined views  ("Kevin Grittner")
Список: pgsql-performance

Скрыть дерево обсуждения

Re: problem with from_collapse_limit and joined views  ("Kevin Grittner", )
 Re: problem with from_collapse_limit and joined views  (Tom Lane, )
  Re: problem with from_collapse_limit and joined views  (Markus Schulz, )
 Re: problem with from_collapse_limit and joined views  (Markus Schulz, )

Am Samstag 04 Dezember 2010 schrieb Kevin Grittner:
> One option would be to create a different user for running queries
> which read from complex views such as this.
>
> postgres=# create user bob;
> CREATE ROLE
> postgres=# alter user bob set from_collapse_limit = 40;
> ALTER ROLE
> postgres=# alter user bob set join_collapse_limit = 40;
> ALTER ROLE
>
> Log in as bob, and your queries should run fine.

thanks, that was really an option for us to use a different user for
creating the reports.

> Nothing leapt out at me as an issue in your postgresql.conf except:
>
> max_prepared_transactions = 20
>
> Do you actually use prepared transactions?  (Sometimes people confuse
> this with prepared statements, which are a completely different
> feature.)

yes, they are needed for our JPA-based j2ee application.

regards
msc


В списке pgsql-performance по дате сообщения:

От: Jochen Erwied
Дата:
Сообщение: Re: Query-plan for partitioned UPDATE/DELETE slow and swaps vmem compared to SELECT
От: John Papandriopoulos
Дата:
Сообщение: Re: Query-plan for partitioned UPDATE/DELETE slow and swaps vmem compared to SELECT