Hi all,
we use schemata to separate our customers in a multi-tenant setup (9.5.7,
Debian stable). Each tenant is managed in his own schema with all the
tables that only he can access. All tables in all schemata are the same in
terms of their DDL: Every tenant uses e.g. his own table 'address'. We
ELECT, INSERT, UPDATE, REFERENCES'::text));
Besides pg_class_oid_index none of the referenced columns is indexed. I
tried to add an index on relowner but didn't succeed because the column is
used in the function call pg_has_role and the query is still forced to do a
sequence scan.
Regard
2017-06-28 10:43 GMT+02:00 Pritam Baral :
>
>
> On Wednesday 28 June 2017 02:00 PM, Ulf Lohbrügge wrote:
> > Nope, I didn't try that yet. But I don't have the impression that
> reindexing the indexes in information_schema will help. The table
> information_schema.t
Hi there,
I'm using PostgreSQL 9.5.9 on Debian and experience slow execution of some
basic SET statements.
I created about 1600 roles and use that setup for a multi tenancy
application:
--snip--
-- create one role per tenant
CREATE ROLE tenant1;
...
CREATE ROLE tenant1600;
-- create admin role
Hi,
2017-11-07 16:11 GMT+01:00 Andres Freund :
> Hi,
>
> On 2017-11-07 11:11:36 +0100, Ulf Lohbrügge wrote:
> > I'm using PostgreSQL 9.5.9 on Debian and experience slow execution of
> some
> > basic SET statements.
> >
> > I created about 1600 rol
2017-11-07 20:45 GMT+01:00 Andres Freund :
> On 2017-11-07 18:48:14 +0100, Ulf Lohbrügge wrote:
> > Hi,
> >
> > 2017-11-07 16:11 GMT+01:00 Andres Freund :
> >
> > > Hi,
> > >
> > > On 2017-11-07 11:11:36 +0100, Ulf Lohbrügge wrote:
> >
2017-11-07 22:39 GMT+01:00 Scott Marlowe :
> On Tue, Nov 7, 2017 at 2:25 PM, Ulf Lohbrügge
> wrote:
> > 2017-11-07 20:45 GMT+01:00 Andres Freund :
> >>
> >> On 2017-11-07 18:48:14 +0100, Ulf Lohbrügge wrote:
> >> > Hi,
> >> >
> >>
2017-11-08 0:45 GMT+01:00 Tom Lane :
> =?UTF-8?Q?Ulf_Lohbr=C3=BCgge?= writes:
> > I just ran "check_postgres.pl --action=bloat" and got the following
> output:
> > ...
> > Looks fine, doesn't it?
>
> A possible explanation is that something is taking an exclusive lock
> on some system catalog and
