Received: from localhost (maia-5.hub.org [200.46.204.182]) by postgresql.org (Postfix) with ESMTP id 9BC229FB3AC for ; Mon, 29 Jan 2007 15:43:09 -0400 (AST) Received: from postgresql.org ([200.46.204.71]) by localhost (mx1.hub.org [200.46.204.182]) (amavisd-new, port 10024) with ESMTP id 83879-08 for ; Mon, 29 Jan 2007 15:42:59 -0400 (AST) X-Greylist: from auto-whitelisted by SQLgrey-1.7.4 Received: from relais.videotron.ca (relais.videotron.ca [24.201.245.36]) by postgresql.org (Postfix) with ESMTP id AE2DF9F9F10 for ; Mon, 29 Jan 2007 15:43:01 -0400 (AST) Received: from [207.253.108.23] by VL-MH-MR001.ip.videotron.ca (Sun Java System Messaging Server 6.2-2.05 (built Apr 28 2005)) with ESMTP id <0JCN00M8EARMYMB0@VL-MH-MR001.ip.videotron.ca> for pgsql-performance@postgresql.org; Mon, 29 Jan 2007 14:43:00 -0500 (EST) Date: Mon, 29 Jan 2007 14:47:46 -0500 From: Carlos Moreno Subject: Re: [OT] Very strange postgresql behaviour In-reply-to: <45BE1589.9030804@andromeiberica.com> To: arnaulist@andromeiberica.com Cc: PostgreSQL Performance Message-id: <45BE4F62.50007@mochima.com> MIME-version: 1.0 Content-type: text/plain; charset=ISO-8859-1; format=flowed Content-transfer-encoding: 7BIT X-Accept-Language: en-us, en References: <45BDE6E4.9050805@andromeiberica.com> <20070129082706.0ef2df3b.wmoran@collaborativefusion.com> <45BE1589.9030804@andromeiberica.com> User-Agent: Mozilla Thunderbird 1.0.8-1.1.fc4 (X11/20060501) X-Virus-Scanned: Maia Mailguard 1.0.1 X-Archive-Number: 200701/409 X-Sequence-Number: 23010 Arnau wrote: > Hi Bill, > >> In response to Arnau : >> >>> I have postgresql 7.4.2 running on debian and I have the oddest >>> postgresql behaviour I've ever seen. >>> >>> I do the following queries: >>> >>> >>> espsm_asme=# select customer_app_config_id, customer_app_config_name >>> from customer_app_config where customer_app_config_id = 5929 or >>> customer_app_config_id = 11527 order by customer_app_config_id; >> Just wild guessing: is there any chance that there may be some form of "implicit" limit modifier for the select statements on this table? Does the behaviour change if you add "limit 2" at the end of the query? Does it change if you use customer_app_config_id in (5929, 11527) instead? Another wild guess: if the data is somewhat corrupt, maybe a vacuum analyze would detect it? Or perhaps try pg_dumping, to see if pg_dump at some point complains about mssing or corrupt data? HTH, Carlos --