Re: [PERFORM] slow queries, possibly disk io

I have some queries that have significan't slowed down in the last couple days. It's gone from 10 seconds to over 2 mins. The cpu has never gone over 35% in the servers lifetime, but the load average is over 8.0 right now. I'm assuming this is probably due to disk io. You sure it's not a severe

Re: [PERFORM] slow queries, possibly disk io

On 5/26/05, Josh Close <[EMAIL PROTECTED]> wrote: > I have some queries that have significan't slowed down in the last > couple days. It's gone from 10 seconds to over 2 mins. > > The cpu has never gone over 35% in the servers lifetime, but the load > average is over 8.0 right now. I'm assuming th

Re: [PERFORM] slow queries, possibly disk io

Josh Close wrote: >I have some queries that have significan't slowed down in the last >couple days. It's gone from 10 seconds to over 2 mins. > >The cpu has never gone over 35% in the servers lifetime, but the load >average is over 8.0 right now. I'm assuming this is probably due to >disk io. > >I

[PERFORM] slow queries, possibly disk io

I have some queries that have significan't slowed down in the last couple days. It's gone from 10 seconds to over 2 mins. The cpu has never gone over 35% in the servers lifetime, but the load average is over 8.0 right now. I'm assuming this is probably due to disk io. I need some help setting up

Re: [PERFORM] Specific query performance problem help requested - postgresql 7.4

Looks like I modified that constraint since the original has '3' and explaining that shows the one I ended up running and posting has 3. Whn I explain on the original version it shows filter: (bucket = 3::bigint) Can you elaborate on what you mean by: > The bucket = 3 rows have to be lurking furt

Re: [PERFORM] Specific query performance problem help requested - postgresql 7.4

"Brad Might" <[EMAIL PROTECTED]> writes: > Can someone help me break this down and figure out why the one query > takes so much longer than the other? It looks to me like there's a correlation between filename and bucket, such that the indexscan in filename order takes much longer to run across th

Re: [PERFORM] Optimising queries involving unions

Sam Mason <[EMAIL PROTECTED]> writes: > Tom Lane wrote: >> It'd be nice to fix this someday, but don't hold your breath ... > Is it even worth me thinking about trying to figure out how to make > the current code do this sort of thing? Probably not :-(. What we need is to integrate UNION (and th

[PERFORM] Specific query performance problem help requested - postgresql 7.4

I am seeing vastly different performance characteristics for almost the exact same query. Can someone help me break this down and figure out why the one query takes so much longer than the other? Looking at the explain analyze output, I see that the loops value on the innermost index scan when b

Re: [PERFORM] Optimising queries involving unions

Tom Lane wrote: >It'd be nice to fix this someday, but don't hold your breath ... Thanks for the response! Is it even worth me thinking about trying to figure out how to make the current code do this sort of thing? or is it just not going to happen with the code as it is? Sam ---

Re: [PERFORM] Optimising queries involving unions

Sam Mason <[EMAIL PROTECTED]> writes: > Here's a bad example: > SELECT u.txt > FROM smalltable t, ( > SELECT id, txt FROM largetable1 > UNION ALL > SELECT id, txt FROM largetable2) u > WHERE t.id = u.id > AND t.foo = 'bar'; > I was hoping that "smalltable" would get moved up

[PERFORM] Optimising queries involving unions

Hi, I've got a query that I think the query optimiser should be able to work it's magic on but it doesn't! I've had a look around and asked on the IRC channel and found that the current code doesn't attempt to optimise for what I'm asking it to do at the moment. Here's a bad example: SELECT u.