> -----Original Message-----
> From: Joel Fradkin [mailto:[EMAIL PROTECTED]
> Sent: Thursday, April 14, 2005 11:39 AM
> To: 'Tom Lane'; 'Dawid Kuroczko'
> Subject: Re: [PERFORM] speed of querry?
> I did as described to alter table and did not see any 
> difference in speed. I am trying to undo the symbolic
> link to the data array and set it up on raid 5 disks in
> the machine just to test if there is an issue with the
> config of the raid 10 array or a problem with the controller.
> I am kinda lame at Linux so not sure I have got it yet still
> testing. Still kind puzzled why it chose tow different option,
> but one is running windows version of postgres, so maybe that
> has something to do with it.

That sounds like a plausible explanation.  However, it could
simply be that the statistics gathered on each box are
sufficiently different to cause different plans.

> The data bases and configs (as far as page cost) are the same.

Did you do as Dawid suggested?

> [...]
> Then do a query couple of times (EXPLAIN ANALYZE also :)), then
> do:
> SET enable_seqscan = off;
> and rerun the query -- if it was significantly faster, you will
> want to do:
> SET enable_seqscan = on;
> and tweak:
> SET random_page_cost = 2.1;
> ...and play with values.  When you reach the random_page_cost
> which suits your data, you will want to put it into
> postgresql.conf
> [...]

This is above and beyond toying with the column statistics.  You
are basically telling the planner to use an index.  Try this,
and post the EXPLAIN ANALYZE for the seqscan = off case on the
slow box if it doesn't speed things up for you.

David B. Held
Software Engineer/Array Services Group
200 14th Ave. East,  Sartell, MN 56377
320.534.3637 320.253.7800 800.752.8129

---------------------------(end of broadcast)---------------------------
TIP 3: if posting/reading through Usenet, please send an appropriate
      subscribe-nomail command to [EMAIL PROTECTED] so that your
      message can get through to the mailing list cleanly

Reply via email to