> -----Original Message-----
> From: Joel Fradkin [mailto:[EMAIL PROTECTED]
> Sent: Thursday, April 14, 2005 11:39 AM
> To: 'Tom Lane'; 'Dawid Kuroczko'
> Cc: 'PERFORM'
> 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
> 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
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