|
Correct, the optimizer did not take the settings with the pg_ctl reload command. I did a pg_ctl restart and work_mem now displays the updated value. I had to bump up all the way to 2047 MB to get the response below (with work_mem at 1024 MB I see 7 seconds response time) and with 2047 MB (which is the max value that can be set for work_mem - anything more than that results in a FATAL error because of the limit) the results are below. The batches and memory usage are reflecting the right behavior with these settings. Thanks for everyones input, the result is now matching what SQL Server was producing. "Hash Join (cost=11305.30..39118.43 rows=92869 width=17) (actual time=145.888..326.216 rows=3163 loops=1)" " Hash Cond: (((pb.id)::text = (pg.id)::text) AND ((pb.question)::text = (pg.question)::text))" " Join Filter: ((COALESCE(pb.response, 'MISSING'::character varying))::text <> (COALESCE(pg.response, 'MISSING'::character varying))::text)" " Buffers: shared hit=6895" " -> Seq Scan on pivotbad pb (cost=0.00..2804.96 rows=93496 width=134) (actual time=0.011..11.903 rows=93496 loops=1)" " Buffers: shared hit=1870" " -> Hash (cost=7537.12..7537.12 rows=251212 width=134) (actual time=145.673..145.673 rows=251212 loops=1)" " Buckets: 32768 Batches: 1 Memory Usage: 39939kB" " Buffers: shared hit=5025" " -> Seq Scan on pivotgood pg (cost=0.00..7537.12 rows=251212 width=134) (actual time=0.004..26.242 rows=251212 loops=1)" " Buffers: shared hit=5025" "Total runtime: 331.168 ms" Humair > CC: tv@xxxxxxxx; humairm@xxxxxxxxxxx; pavel.stehule@xxxxxxxxx; pgsql-performance@xxxxxxxxxxxxxx > From: robertmhaas@xxxxxxxxx > Subject: Re: Query Performance SQL Server vs. Postgresql > Date: Sun, 21 Nov 2010 13:55:54 -0500 > To: tgl@xxxxxxxxxxxxx > > On Nov 21, 2010, at 12:16 PM, Tom Lane <tgl@xxxxxxxxxxxxx> wrote: > > tv@xxxxxxxx writes: > >>> Second, I modified the work_mem setting to 2GB (reloaded config) and I see > >>> a response time of 38 seconds. Results below from EXPLAIN ANALYZE: > > > >> How did you reload the config? Using 'kill -HUP pid'? That should work > >> fine. Have you cheched 'work_mem' after the reload? > > > >> Because the explain plans are exactly the same (structure, estimated > >> costs). The really interesting bit is this and it did not change at all > > > >> Buckets: 1024 Batches: 64 Memory Usage: 650kB > > > > If that didn't change, I'm prepared to bet that the OP didn't actually > > manage to change the active value of work_mem. > > Yep. All this speculation about slow disks and/or COALESCE strikes me as likely totally off-base. I think the original poster needs to run "show work_mem" right before the EXPLAIN ANALYZE to make sure the new value they set actually stuck. There's no reason for the planner to have used only 650kB if work_mem is set to anything >=2MB. > > ...Robert |
