Re: [PERFORM] Slow Query- Simple taking

2010-10-28 Thread Robert Haas
On Thu, Oct 28, 2010 at 11:23 AM, Mladen Gogala wrote: > On 10/28/2010 10:53 AM, Richard Broersma wrote: >> >> On Thu, Oct 28, 2010 at 7:51 AM, Mladen Gogala >>  wrote: >> >>> Yyesss! Any time frame on that? Can you make it into 9.0.2? >> >> Maybe 9.1.0 or 9.2.0 :)  9.0's features are already fro

Re: [PERFORM] Slow Query- Simple taking

2010-10-28 Thread Mladen Gogala
On 10/28/2010 10:53 AM, Richard Broersma wrote: On Thu, Oct 28, 2010 at 7:51 AM, Mladen Gogala wrote: Yyesss! Any time frame on that? Can you make it into 9.0.2? Maybe 9.1.0 or 9.2.0 :) 9.0's features are already frozen. Well, with all this global warming around us, index scans may still

Re: [PERFORM] Slow Query- Simple taking

2010-10-28 Thread Richard Broersma
On Thu, Oct 28, 2010 at 7:51 AM, Mladen Gogala wrote: > Yyesss! Any time frame on that? Can you make it into 9.0.2? Maybe 9.1.0 or 9.2.0 :) 9.0's features are already frozen. -- Regards, Richard Broersma Jr. Visit the Los Angeles PostgreSQL Users Group (LAPUG) http://pugs.postgresql.org/lap

Re: [PERFORM] Slow Query- Simple taking

2010-10-28 Thread Mladen Gogala
On 10/28/2010 10:42 AM, Robert Haas wrote: I can believe that MySQL is faster, because they probably don't need to do the bitmap heap scan. There is a much-anticipated feature called index-only scans that we don't have yet in PG, which would help cases like this a great deal. Yyesss! Any time f

Re: [PERFORM] Slow Query- Simple taking

2010-10-28 Thread Robert Haas
On Tue, Oct 19, 2010 at 6:05 PM, Ozer, Pam wrote: > On mysql the same query only takes milliseconds not seconds.  That's a > big difference. I can believe that MySQL is faster, because they probably don't need to do the bitmap heap scan. There is a much-anticipated feature called index-only scan

Re: [PERFORM] Slow Query- Simple taking

2010-10-28 Thread Robert Haas
On Thu, Oct 28, 2010 at 10:39 AM, Robert Haas wrote: >> Can someone tell me why after it runs the index scan it hen runs a bitmap >> heap scan?  It should not take this long to run should it?  If I limit the >> results it comes back in 300ms. > > It doesn't.  The EXPLAIN output shows it running th

Re: [PERFORM] Slow Query- Simple taking

2010-10-28 Thread Robert Haas
On Tue, Oct 19, 2010 at 2:21 PM, Ozer, Pam wrote: > I have the following query running on 8.4, which takes 3516 ms.  It is very > straight forward.  It brings back 116412 records.  The explain only takes > 1348ms > > select VehicleUsed.VehicleUsedId as VehicleUsedId , > > VehicleUsed.VehicleUsedDi

Re: [PERFORM] Slow Query- Simple taking

2010-10-19 Thread Ozer, Pam
On mysql the same query only takes milliseconds not seconds. That's a big difference. -Original Message- From: Kevin Grittner [mailto:kevin.gritt...@wicourts.gov] Sent: Tuesday, October 19, 2010 1:59 PM To: Ozer, Pam; pgsql-performance@postgresql.org Subject: Re: [PERFORM] Slow

Re: [PERFORM] Slow Query- Simple taking

2010-10-19 Thread Mathieu De Zutter
On Tue, Oct 19, 2010 at 8:21 PM, Ozer, Pam wrote: > I have the following query running on 8.4, which takes 3516 ms.  It is very > straight forward.  It brings back 116412 records.  The explain only takes > 1348ms > "Sort  (cost=104491.48..105656.24 rows=116476 width=41) (actual > time=1288.413..1

Re: [PERFORM] Slow Query- Simple taking

2010-10-19 Thread Kevin Grittner
"Ozer, Pam" wrote: > I have the following query running on 8.4, which takes 3516 ms. > It is very straight forward. It brings back 116412 records. The > explain only takes 1348ms The EXPLAIN ANALYZE doesn't have to return 116412 rows to the client. It doesn't seem too out of line to me tha

[PERFORM] Slow Query- Simple taking

2010-10-19 Thread Ozer, Pam
I have the following query running on 8.4, which takes 3516 ms. It is very straight forward. It brings back 116412 records. The explain only takes 1348ms select VehicleUsed.VehicleUsedId as VehicleUsedId , VehicleUsed.VehicleUsedDisplayPriority as VehicleUsedDisplayPriority , VehicleUsed