DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws; s=s1024; d=yahoo.com.br;
	h=Message-ID:Received:Date:From:Subject:To:MIME-Version:Content-Type:Content-Transfer-Encoding;
	b=lsthmKHhluywJpM8rvQ23N2bw6V5BG2HVnT8pUMe4uCMs4liAC+lOPboB5+NvhFeTMgD0kUO/jFWMvUmHYPi5phXRb+XjS7AH3mfuX0zfeDaoB96ldzscYX/zt1TR29j3D6UDdtD7j1Dg8x+P8e2y65lpIHqgZh+BveKMX5BMTA=
	;
Message-ID: <20051210152937.71243.qmail@web36410.mail.mud.yahoo.com>
Date: Sat, 10 Dec 2005 15:29:37 +0000 (GMT)
From: Henrique Engelmann <henriqueengelmann@yahoo.com.br>
Subject: Clustered tables and seqscan disabled
To: pgsql-performance@postgresql.org
MIME-Version: 1.0
Content-Type: multipart/alternative; boundary="0-826323334-1134228577=:53389"
Content-Transfer-Encoding: 8bit

--0-826323334-1134228577=:53389
Content-Type: text/plain; charset=iso-8859-1
Content-Transfer-Encoding: 8bit

Hi,
   
  Sometime ago I worked in an implantation project that uses postgresql and I remember than the software house recommended us to use seqscan off...
I was not very sure, but I thought the best way should be set seqscan on and let postgresql choose the best access plan (index or seqscan). Even against the other team members I changed the configuration to seqscan on and the system didn´t worked anymore.
   
  Studying better the reasons I verified that applications were expecting data in primary index order but with seqscan ON sometimes postgresql didn´t use an index and naturally data came without order.
   
  I suggested changing the application and including  a order by clause... but
the software house didn´t make it because they said the system was originally designed for oracle and they did not need to use the ORDER BY clause with Oracle and even so the data were always retrieved in primary index order.
   
  I´m thinking with myself ... what kind of problems will they have in the future?
   
  I think this kind of configuration is very dependent of clustered tables... Am I right?
   
  Best regards!

  Engelmann.

__________________________________________________
Faça ligações para outros computadores com o novo Yahoo! Messenger 
http://br.beta.messenger.yahoo.com/ 
--0-826323334-1134228577=:53389
Content-Type: text/html; charset=iso-8859-1
Content-Transfer-Encoding: 8bit

<DIV id=RTEContent>Hi,</DIV>  <DIV>&nbsp;</DIV>  <DIV>Sometime ago I worked in an implantation project that uses postgresql and I remember than the software house recommended us to use seqscan off...<BR>I was not very sure, but I thought the best way should be set seqscan on and let postgresql choose the best access plan (index or seqscan). Even against the other team members I changed the configuration to seqscan on and the system didn´t worked anymore.</DIV>  <DIV>&nbsp;</DIV>  <DIV>Studying better the reasons I verified that applications were expecting data in primary index order but with seqscan ON sometimes postgresql didn´t use an index and naturally data came without order.</DIV>  <DIV>&nbsp;</DIV>  <DIV>I suggested changing the application and including&nbsp;&nbsp;a order by clause... but<BR>the software house didn´t make it because they said the system was originally designed for oracle and they did not need to use the ORDER BY clause with Oracle and even so the data
  were
 always retrieved in primary index order.</DIV>  <DIV>&nbsp;</DIV>  <DIV>I´m thinking with myself ... what kind of problems will they have in the future?</DIV>  <DIV>&nbsp;</DIV>  <DIV>I think this kind of configuration is very dependent of clustered tables... Am I right?</DIV>  <DIV>&nbsp;</DIV>  <DIV>Best regards!<BR></DIV>  <DIV>Engelmann.</DIV><p>__________________________________________________<br>Faça ligações para outros computadores com o novo Yahoo! Messenger <br>http://br.beta.messenger.yahoo.com/ 
--0-826323334-1134228577=:53389--