Re: [PERFORM] Estimation row error

Sorry, I forget to precise Postgresql version 'PostgreSQL 9.4.4 on x86_64-unknown-linux-gnu, compiled by gcc (GCC) 4.4.7 20120313 (Red Hat 4.4.7-11), 64-bit' BR Mathieu VINCENT 2015-12-11 9:53 GMT+01:00 Mathieu VINCENT : > Hello, > > I would like to know how

Re: [PERFORM] partitioned table set and indexes

> Rick Otten hat am 11. Dezember 2015 um 21:40 > geschrieben: > > > I do not know why if I blast a new index creation on the 20 or so children > all at once some of them fail, but then if I go back and do a few at a time > they all work. It has happened to me 3

Re: [PERFORM] checkpoints, proper config

On 12/10/15 2:58 PM, Tory M Blue wrote: This is a slony slave node, so I'm not too worried about this particular host losing it's data, thus fsync is off, The Amazon RDS team actually benchmarked fsync=off vs sync commit off and discovered that you get better performance turning sync commit

Re: [PERFORM] partitioned table set and indexes

> Rick Otten hat am 11. Dezember 2015 um 23:09 > geschrieben: > > The query performance hit for sequence scanning isn't all that terrible, > but I'd rather understand and get rid of the issue if I can, now, before I > run into it again in a situation where it is

Re: [PERFORM] partitioned table set and indexes

On Fri, Dec 11, 2015 at 1:01 PM, Rick Otten wrote: > The first thing I noticed, when creating indexes on the 20 or so partitions, > was that if I create them too fast they don't all succeed. I have to do a > few at a time, let them breathe for a few seconds, and then

Re: [PERFORM] Advise needed for a join query with a where conditional

On 12/10/15 10:38 PM, ankur_adwyze wrote: I have a Rails app with Postgres db. For certain reports, I have to join multiple tables. However, certain join queries are dog slow and I am wondering if I am missing any index. My guess is that the planner is coming up with a bad estimate. Please

Re: [PERFORM] partitioned table set and indexes

Ok, here is the first case where I select on the column: http://explain.depesz.com/s/ECb Here is the second case where I try a join: http://explain.depesz.com/s/qIu And here is the third case where I add a filter on the parent table: http://explain.depesz.com/s/1es The primary use

Re: [PERFORM] checkpoints, proper config

On 12/10/15 7:20 PM, Tomas Vondra wrote: I agree, but actually, what is the sense of checkpoint_warning? I think it was useful back when we didn't have log_checkpoints, but now that we have detailed checkpoint logging I think it's pretty much useless noise. Not entirely. The WARNING only

Re: [PERFORM] partitioned table set and indexes

> Rick Otten hat am 12. Dezember 2015 um 01:55 > geschrieben: > > > Why does it index scan when I use where, but not when I do a join? difficult to say/guess because of anonymized names and not knowing the real query. This one? http://explain.depesz.com/s/1es ? All

Re: [PERFORM] partitioned table set and indexes

Rick Otten wrote: > I'm using PostgreSQL 9.5 Beta 2. > > I am working with a partitioned table set. > > The first thing I noticed, when creating indexes on the 20 or so partitions, > was that if I create them too fast they don't all succeed.  I have to do a few > at a

Re: [PERFORM] partitioned table set and indexes

I do not know why if I blast a new index creation on the 20 or so children all at once some of them fail, but then if I go back and do a few at a time they all work. It has happened to me 3 times now, so I'm pretty sure I'm not imagining it. What specifically in the explain analyze output tells

[PERFORM] partitioned table set and indexes

I'm using PostgreSQL 9.5 Beta 2. I am working with a partitioned table set. The first thing I noticed, when creating indexes on the 20 or so partitions, was that if I create them too fast they don't all succeed. I have to do a few at a time, let them breathe for a few seconds, and then do a few

[PERFORM] Estimation row error

Hello, I would like to know how row estimation is calculed by explain ? In my execution plan, this estimation is extremely wrong (267 instead of 198000) I reproduced this estimation error in this simple case : drop table if exists t1; drop table if exists t2; drop table if exists t3; drop table

Re: [PERFORM] partitioned table set and indexes

Why does it index scan when I use where, but not when I do a join? On Fri, Dec 11, 2015 at 7:20 PM, Andreas Kretschmer wrote: > > > Rick Otten hat am 11. Dezember 2015 um 23:09 > > geschrieben: > > > > > The query performance hit for sequence