Re: [PERFORM] Improving Inner Join Performance

2006-01-11 Thread Jim C. Nasby
gt; - Original Message - > > From: "Frank Wiles" <[EMAIL PROTECTED]> > To: "Andy" <[EMAIL PROTECTED]> > Sent: Friday, January 06, 2006 7:12 PM > Subject: Re: [PERFORM] Improving Inner Join Performance > > > > On Fri, 6 Jan 2006 09:59:30

Re: [PERFORM] Improving Inner Join Performance

2006-01-08 Thread Andy
shared_buffers = 10240effective_cache_size = 64000RAM on server: 1Gb. Andy. - Original Message - From: "Frank Wiles" <[EMAIL PROTECTED]> To: "Andy" <[EMAIL PROTECTED]> Sent: Friday, January 06, 2006 7:12 PM Subject: Re: [PERFORM] Improving Inner J

Re: [PERFORM] Improving Inner Join Performance

2006-01-06 Thread Jaime Casanova
On 1/6/06, Andy <[EMAIL PROTECTED]> wrote: > At the moment: o.id_status>3 can have values only 4 and 6. The 6 is around > 90% from the whole table. This is why seq scan is made. > given this if you make id_status > 3 you will never use an index because you will be scanning 4 and 6 the only values i

Re: [PERFORM] Improving Inner Join Performance

2006-01-06 Thread Andy
the user can have. I use this to build pages of results. Andy. - Original Message - From: "Pandurangan R S" <[EMAIL PROTECTED]> To: "Andy" <[EMAIL PROTECTED]> Cc: Sent: Friday, January 06, 2006 11:56 AM Subject: Re: [PERFORM] Improving Inner Join Performance

Re: [PERFORM] Improving Inner Join Performance

2006-01-06 Thread Pandurangan R S
> If the users puts in some other search fields on the where then the query > runs faster but > in this format sometimes it takes a lot lot of > time(sometimes even 2,3 seconds). Can you eloborate under what conditions which query is slower? On 1/5/06, Andy <[EMAIL PROTECTED]> wrote: > > Hi to

Re: [PERFORM] Improving Inner Join Performance

2006-01-06 Thread Andy
Sorry, I had to be more specific. VACUUM ANALYZE is performed every hour. Regards, Andy. - Original Message - From: "Michael Glaesemann" <[EMAIL PROTECTED]> To: "Andy" <[EMAIL PROTECTED]> Cc: Sent: Friday, January 06, 2006 11:45 AM Subject: Re

Re: [PERFORM] Improving Inner Join Performance

2006-01-06 Thread Michael Glaesemann
On Jan 6, 2006, at 18:21 , Andy wrote: Yes I have indexes an all join fields. The tables have around 30 columns each and around 100k rows. The database is vacuumed every hour. Just to chime in, VACUUM != VACUUM ANALYZE. ANALYZE is what updates database statistics and affects query planni

Re: [PERFORM] Improving Inner Join Performance

2006-01-06 Thread Andy
ursday, January 05, 2006 9:20 PM Subject: Re: [PERFORM] Improving Inner Join Performance On Thu, 5 Jan 2006 17:16:47 +0200 "Andy" <[EMAIL PROTECTED]> wrote: Hi to all, I have the following query: SELECT count(*) FROM orders o INNER JOIN report r ON r.id_order=o.id

Re: [PERFORM] Improving Inner Join Performance

2006-01-05 Thread Frank Wiles
On Thu, 5 Jan 2006 17:16:47 +0200 "Andy" <[EMAIL PROTECTED]> wrote: > Hi to all, > > I have the following query: > > SELECT count(*) FROM orders o > INNER JOIN report r ON r.id_order=o.id > WHERE o.id_status>3 > How can I improve this query's performace?? The ideea is to count all

[PERFORM] Improving Inner Join Performance

2006-01-05 Thread Andy
Hi to all,   I have the following query:   SELECT count(*) FROM orders o  INNER JOIN report r ON r.id_order=o.id  WHERE o.id_status>3   Explaing analyze: Aggregate  (cost=8941.82..8941.82 rows=1 width=0) (actual time=1003.297..1003.298 rows=1 loops=1)  ->  Hash Join  (cost=3946.28.