Never say never with computer geeks .... http://www.youtube.com/watch?v=mJyAA0oPAwE
On Fri, Jun 11, 2010 at 7:44 AM, Kenneth Marshall <k...@rice.edu> wrote: > Hi Anj, > > That is an indication that your system was less correctly > modeled with a random_page_cost=2 which means that the system > will assume that random I/O is cheaper than it is and will > choose plans based on that model. If this is not the case, > the plan chosen will almost certainly be slower for any > non-trivial query. You can put a 200mph speedometer in a > VW bug but it will never go 200mph. > > Regards, > Ken > > On Thu, Jun 10, 2010 at 07:54:01PM -0700, Anj Adu wrote: > > I changed random_page_cost=4 (earlier 2) and the performance issue is > gone > > > > I am not clear why a page_cost of 2 on really fast disks would perform > badly. > > > > Thank you for all your help and time. > > > > On Thu, Jun 10, 2010 at 8:32 AM, Anj Adu <fotogra...@gmail.com> wrote: > > > Attached > > > > > > Thank you > > > > > > > > > On Thu, Jun 10, 2010 at 6:28 AM, Robert Haas <robertmh...@gmail.com> > wrote: > > >> On Wed, Jun 9, 2010 at 11:17 PM, Anj Adu <fotogra...@gmail.com> > wrote: > > >>> The plan is unaltered . There is a separate index on theDate as well > > >>> as one on node_id > > >>> > > >>> I have not specifically disabled sequential scans. > > >> > > >> Please do "SHOW ALL" and attach the results as a text file. > > >> > > >>> This query performs much better on 8.1.9 on a similar sized > > >>> table.(althought the random_page_cost=4 on 8.1.9 and 2 on 8.4.0 ) > > >> > > >> Well that could certainly matter... > > >> > > >> -- > > >> Robert Haas > > >> EnterpriseDB: http://www.enterprisedb.com > > >> The Enterprise Postgres Company > > >> > > > > > > > -- > > Sent via pgsql-performance mailing list ( > pgsql-performance@postgresql.org) > > To make changes to your subscription: > > http://www.postgresql.org/mailpref/pgsql-performance > > > > -- > Sent via pgsql-performance mailing list (pgsql-performance@postgresql.org) > To make changes to your subscription: > http://www.postgresql.org/mailpref/pgsql-performance >