Re: [PERFORM] Best design for performance

> From: Claudio Freire [mailto:klaussfre...@gmail.com] > > How did you query the table's size? You're probably failing to account for > TOAST tables. > > I'd suggest using pg_total_relation_size. ... On Mon, Mar 27, 2017 at 10:17 PM, Riaan Stander wrote: > I'm using the first

[PERFORM] Best design for performance

Good day At my company we're busy converting a product from using SQL Server to Postgres. One part of the old design involves filtering data for the rights a user has. The SQL Server table looked like this: CREATE TABLE [dbo].[usrUserRights] ( [UserId] [dbo].[dm_Id] NOT NULL,

Re: [PERFORM] Performance issue after upgrading from 9.4 to 9.6

On Mon, Mar 6, 2017 at 7:20 AM, Piotr Gasidło wrote: > We are having some performance issues after we upgraded to newest > version of PostgreSQL, before it everything was fast and smooth. > > Upgrade was done by pg_upgrade from 9.4 directly do 9.6.1. Now we > upgraded to

Re: [PERFORM] Postgres not using all RAM (Huge Page activated on a 96GB RAM system)

On Fri, Mar 24, 2017 at 2:47 PM, Scott Marlowe wrote: > On Fri, Mar 24, 2017 at 3:58 AM, Pietro Pugni wrote: >> Hi there, >> I’m running PostgreSQL 9.6.2 on Ubuntu 16.04.2 TLS (kernel >> 4.4.0-66-generic). Hardware is: >> - 2 x Intel Xeon E5-2690

Re: [PERFORM] Best design for performance

On Mon, Mar 27, 2017 at 8:43 PM, Riaan Stander wrote: > In Postgres I was thinking of going with a design like this > > CREATE TABLE security.user_right_site > ( > user_id bigint NOT NULL, > right_id bigint NOT NULL, > sites bigint[] > ); > create index on

Re: [PERFORM] Best design for performance

I'm using the first query from here. https://wiki.postgresql.org/wiki/Disk_Usage It does seem to include toast data. The plan is to do the rights checking in the application. The join solution gets used for reports to filter data & client adhoc queries. -Original Message- From: Claudio