Re: [PERFORM] Query performance over a large proportion of data

2009-03-10 Thread Steve McLellan
> > > > *"Kevin Grittner" * > 03/10/2009 05:06 PM EST > > > enable_seqscan = off > > Not a good idea; some queries will optimize better with seqscans. > You can probably get the behavior you want using other adjustments. > The bullet to cure the headache, as Scott said. > > You probably need to re

Re: [PERFORM] Query performance over a large proportion of data

2009-03-10 Thread Steve McLellan
> > > *Scott Marlowe * > 03/10/2009 05:19 PM > > > > > Nested Loop (cost=466.34..192962.24 rows=15329 width=12) (actual > > time=13653.238..31332.113 rows=131466 loops=1) > > > Both your query plans end with this nested loop join which is taking > up about half your time in your query. Notice th

Re: [PERFORM] Query performance over a large proportion of data

2009-03-10 Thread Steve McLellan
> > > > *Tom Lane * > Sent by: pgsql-performance-ow...@postgresql.org > 03/10/2009 08:16 PM AST > > "Steve McLellan" writes: > > lc_messages = 'en_US.UTF-8' > > lc_monetary = 'en_US.UTF-8' > > lc_numeric = 'en_US.UTF-8&

[PERFORM] Query performance over a large proportion of data

2009-03-10 Thread Steve McLellan
Hi, I'd be grateful for any advice we can get... we recently switched from MySQL to PostgreSQL on the basis of some trials we carried out with datasets of varying sizes and varying rates of contention. For the most part we've been pleased with performance, but one particular application runs queri