Re: Query much faster with enable_seqscan=0
От
Joshua D. Drake
Тема
Re: Query much faster with enable_seqscan=0
Дата
Msg-id
1285096031.15919.68.camel@jd-desktop.iso-8859-1.charter.com
Ответ на
Список
Дерево обсуждения
Query much faster with enable_seqscan=0 Ogden <lists@darkstatic.com>
Re: Query much faster with enable_seqscan=0 Tom Lane <tgl@sss.pgh.pa.us>
Re: Query much faster with enable_seqscan=0 Ogden <lists@darkstatic.com>
Re: Query much faster with enable_seqscan=0 Samuel Gendler <sgendler@ideasculptor.com>
Re: Query much faster with enable_seqscan=0 Robert Haas <robertmhaas@gmail.com>
Re: Query much faster with enable_seqscan=0 Kenneth Marshall <ktm@rice.edu>
Re: Query much faster with enable_seqscan=0 Ogden <lists@darkstatic.com>
Re: Query much faster with enable_seqscan=0 Jesper Krogh <jesper@krogh.cc>
Re: Query much faster with enable_seqscan=0 Ogden <lists@darkstatic.com>
Re: Query much faster with enable_seqscan=0 "Joshua D. Drake" <jd@commandprompt.com>
Re: Query much faster with enable_seqscan=0 "Joshua D. Drake" <jd@commandprompt.com>
Re: Query much faster with enable_seqscan=0 Greg Smith <greg@2ndquadrant.com>
Re: Query much faster with enable_seqscan=0 Tom Lane <tgl@sss.pgh.pa.us>
Re: Query much faster with enable_seqscan=0 Ogden <lists@darkstatic.com>
Re: Query much faster with enable_seqscan=0 Ogden <lists@darkstatic.com>
Re: Query much faster with enable_seqscan=0 Robert Haas <robertmhaas@gmail.com>
Re: Query much faster with enable_seqscan=0 Scott Carey <scott@richrelevance.com>
On Tue, 2010-09-21 at 14:02 -0500, Ogden wrote: > How odd, I set the following: > > seq_page_cost = 1.0 > random_page_cost = 2.0 > > And now the query runs in milliseconds as opposed to 14 seconds. Could this really be the change? I am running ANALYZE now - how often is it recommended to do this? PostgreSQL's defaults are based on extremely small and some would say (non production) size databases. As a matter of course I always recommend bringing seq_page_cost and random_page_cost more in line. However, you may want to try moving random_page_cost back to 4 and try increasing cpu_tuple_cost instead. Sincerely, Joshua D. Drake -- PostgreSQL.org Major Contributor Command Prompt, Inc: http://www.commandprompt.com/ - 509.416.6579 Consulting, Training, Support, Custom Development, Engineering http://twitter.com/cmdpromptinc | http://identi.ca/commandprompt
В списке pgsql-performance по дате отправления
От: Craig Ringer
Дата: