Re: [PERFORM] Different query plans for the same query

2009-09-23 Thread Hell, Robert
: Freitag, 18. September 2009 17:43 An: Hell, Robert Cc: t...@fuzzy.cz; pgsql-performance@postgresql.org Betreff: Re: [PERFORM] Different query plans for the same query "Hell, Robert" writes: > bad plan (sometimes with statistcs target 100, seconds after the good plan > was c

Re: [PERFORM] Different query plans for the same query

2009-09-18 Thread Robert Haas
2009/9/18 : >> Hi all, >> >> on our PostgreSQL 8.3.1 (CentOS 5.3 64-bit) two different query plans >> for one of our (weird) queries are generated. One of the query plans >> seems to be good (and is used most of the time). The other one is bad - >> the query takes about 2 minutes and the database

Re: [PERFORM] Different query plans for the same query

2009-09-18 Thread Tom Lane
"Hell, Robert" writes: > bad plan (sometimes with statistcs target 100, seconds after the good plan > was chosen) - about 2 minutes: http://explain.depesz.com/s/gcr > good plan (most of the time with statistcs target 100) - about one second: > http://explain.depesz.com/s/HX > very good plan (wit

Re: [PERFORM] Different query plans for the same query

2009-09-18 Thread Hell, Robert
org Betreff: Re: [PERFORM] Different query plans for the same query > Hi all, > > on our PostgreSQL 8.3.1 (CentOS 5.3 64-bit) two different query plans > for one of our (weird) queries are generated. One of the query plans > seems to be good (and is used most of the time). The other one is b

Re: [PERFORM] Different query plans for the same query

2009-09-18 Thread tv
> Hi all, > > on our PostgreSQL 8.3.1 (CentOS 5.3 64-bit) two different query plans > for one of our (weird) queries are generated. One of the query plans > seems to be good (and is used most of the time). The other one is bad - > the query takes about 2 minutes and the database process, which is >

[PERFORM] Different query plans for the same query

2009-09-18 Thread Hell, Robert
Hi all, on our PostgreSQL 8.3.1 (CentOS 5.3 64-bit) two different query plans for one of our (weird) queries are generated. One of the query plans seems to be good (and is used most of the time). The other one is bad - the query takes about 2 minutes and the database process, which is executing th