Re: [PERFORM] Selectivity for lopsided foreign key columns

2015-12-17 Thread Mikkel Lauritsen
On 2015-12-17 16:23, Tom Lane wrote: Mikkel Lauritsen writes: The schema contains two tables, t1 and t2. t2 has two fields, an id and a tag, and it contains 146 rows that are unique. t1 has two fields, a value and a foreign key referring to t2.id, and it contains 266177 rows. The application

Re: [PERFORM] Terrible plan choice for view with distinct on clause

2015-12-17 Thread Adam Brusselback
Also, sorry if I wasn't clear. Those two example queries above that performed badly were not exact queries that I would use, they were just simple examples that performed identically to something like this (or the exists version of the same query): SELECT cp.* FROM contract_product cp INNER JOIN c

Re: [PERFORM] Terrible plan choice for view with distinct on clause

2015-12-17 Thread Adam Brusselback
No ORM, just me. Was somewhat similar to something I had seen done at an old job, but they used SQL Server and that type of query worked fine there. There were a couple business cases that had to be satisfied, which is why I went the way I did: The first was "allow products to be grouped together,

Re: [PERFORM] Can't explain db size

2015-12-17 Thread Matteo Grolla
also, serializable_value is of type bytea 2015-12-17 16:12 GMT+01:00 Matteo Grolla : > have news, > the pg version is 9.1.3 > a vaccum full, not a plain vaccum, was performed. > o.s. is red hat 7 > filesystem: xfs with block size 4k > > could it be a problem regarding the

Re: [PERFORM] Terrible plan choice for view with distinct on clause

2015-12-17 Thread Tom Lane
Adam Brusselback writes: > The view I am having trouble with is able to push down it's where clause > when the id's are directly specified like so: > SELECT * > FROM contract_product cp > WHERE cp.contract_id = '16d6df05-d8a0-4ec9-ae39-f4d8e13da597' > AND cp.product_id = '00c117d7-6451-4842-b17b-b

[PERFORM] Terrible plan choice for view with distinct on clause

2015-12-17 Thread Adam Brusselback
Hey all, first off, Postgres version 9.4.4 (also tested on 9.5 beta). I have been having a pretty hard time getting a view of mine to play nice with any other queries I need it for. I have a few tables you'd need to know about to understand why i'm doing what i'm doing. First thing is we have a

Re: [PERFORM] Selectivity for lopsided foreign key columns

2015-12-17 Thread Tom Lane
Mikkel Lauritsen writes: > The schema contains two tables, t1 and t2. > t2 has two fields, an id and a tag, and it contains 146 rows that are > unique. > t1 has two fields, a value and a foreign key referring to t2.id, and it > contains 266177 rows. > The application retrieves the rows in t1 tha

Re: [PERFORM] Can't explain db size

2015-12-17 Thread Matteo Grolla
have news, the pg version is 9.1.3 a vaccum full, not a plain vaccum, was performed. o.s. is red hat 7 filesystem: xfs with block size 4k could it be a problem regarding the block size? thanks 2015-12-15 12:11 GMT+01:00 Matteo Grolla : > Thanks Andreas, > Il try > >

Re: [PERFORM] Estimation row error

2015-12-17 Thread Mathieu VINCENT
Adding foreign key between on t2 and t3, does not change the plan. drop table if exists t1; drop table if exists t2; drop table if exists t3; create table t1 as select generate_Series(1,20) as c1; create table t2 as select generate_Series(1,20)%100+1 as c1; create table t3 as select gener

Re: [PERFORM] Estimation row error

2015-12-17 Thread Mathieu VINCENT
Here, another issue with row estimate. And, in this example, there is not correlation beetween columns in a same table. drop table if exists t1; drop table if exists t2; drop table if exists t3; create table t1 as select generate_Series(1,20) as c1; create table t2 as select generate_Series(1

[PERFORM] Selectivity for lopsided foreign key columns

2015-12-17 Thread Mikkel Lauritsen
Hi all, I have an application that runs in production in multiple instances, and on one of these the performance of certain queries suddenly became truly abysmal. I basically know why, but I would much appreciate if I could obtain a deeper understanding of the selectivity function involved and

Re: [PERFORM] Estimation row error

2015-12-17 Thread Matteo Grolla
Thank you both for the help! happy holidays 2015-12-17 10:10 GMT+01:00 Mathieu VINCENT : > thks Gunnar, > > I removed the correlation between t3.c1 and t3.c2 in this sql script : > > drop table if exists t1; > drop table if exists t2; > drop table if exists t3; > drop table if exists t4; > > crea

Re: [PERFORM] Estimation row error

2015-12-17 Thread Mathieu VINCENT
thks Gunnar, I removed the correlation between t3.c1 and t3.c2 in this sql script : drop table if exists t1; drop table if exists t2; drop table if exists t3; drop table if exists t4; create table t1 as select generate_Series(1,30) as c1; create table t2 as select generate_Series(1,400) as c