Re: Implications of having large number of users

От: Albe Laurenz
Тема: Re: Implications of having large number of users
Дата: ,
Msg-id: D960CB61B694CF459DCFB4B0128514C202FF6677@exadv11.host.magwien.gv.at
(см: обсуждение, исходный текст)
Ответ на: Implications of having large number of users  (Mike Ivanov)
Ответы: Re: Implications of having large number of users  (Robert Haas)
Список: pgsql-performance

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

Implications of having large number of users  (Mike Ivanov, )
 Re: Implications of having large number of users  ("Albe Laurenz", )
  Re: Implications of having large number of users  (Robert Haas, )
   Re: Implications of having large number of users  ("Albe Laurenz", )
    Re: Implications of having large number of users  (Tom Lane, )
     Re: Implications of having large number of users  (Robert Haas, )
 Re: Implications of having large number of users  (Mike Ivanov, )

Mike Ivanov wrote:
> Please help me to make a decision on how to manage users.
>
> For some reason it is easier in the project I'm working on to split data
> by schemes and assign them to Postgres' users (I mean those created with
> CREATE USER) rather than support 'owner' fields referring to a global
> users table.

You know that (unlike in Oracle) user and schema is not coupled in
PostgreSQL, right? So you can have one user owning tables in various schemata
and many users owning tables in one schema.

> The question is what could be the consequences of having a large number
> of them (tens of thousands)?

It shouldn't be a problem.
The only critical number is the number of concurrent connections
at a given time.

> Context:
>
> - it is a web app
> - thousands of concurrent requests from different users
> - amount of user's data in the db is relatively small
>
> Concerns:
>
> - how big is the performance/memory penalty on switching users in the
> same connection (connections are reused of course)?
> - will it hurt the cache?
> - are prepared statements kept per user or per connection?
> - is the query planner global or somehow tied to users?
>
> I'd be glad to hear any opinions/suggestions.

You cannot keep the connection and change users.
A change of database user always means a new connection and a new backend
process.

Yours,
Laurenz Albe


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

От: Robert Haas
Дата:
Сообщение: Re: Implications of having large number of users
От: Alvaro Herrera
Дата:
Сообщение: Re: tsvector_update_trigger performance?