X-Original-To: pgsql-docs-postgresql.org@localhost.postgresql.org Received: from localhost (unknown [200.46.204.144]) by svr1.postgresql.org (Postfix) with ESMTP id 8A2E95E46F4 for ; Tue, 31 Aug 2004 13:30:50 -0300 (ADT) Received: from svr1.postgresql.org ([200.46.204.71]) by localhost (av.hub.org [200.46.204.144]) (amavisd-new, port 10024) with ESMTP id 74106-02 for ; Tue, 31 Aug 2004 16:30:52 +0000 (GMT) Received: from window.monsterlabs.com (window.monsterlabs.com [216.183.105.176]) by svr1.postgresql.org (Postfix) with SMTP id 1FE265E46C3 for ; Tue, 31 Aug 2004 13:30:43 -0300 (ADT) Received: (qmail 28784 invoked from network); 31 Aug 2004 16:30:50 -0000 Received: from pcp09180741pcs.nash01.tn.comcast.net (HELO ?192.168.0.106?) (68.53.156.196) by 0 with SMTP; 31 Aug 2004 16:30:50 -0000 Mime-Version: 1.0 (Apple Message framework v619) Content-Type: text/plain; charset=US-ASCII; format=flowed Message-Id: <1BDAA016-FB6B-11D8-A844-000D93AE0944@sitening.com> Content-Transfer-Encoding: 7bit Cc: pgsql-docs@postgresql.org From: Thomas F.O'Connell Subject: FAQ -- Index usage/speed Date: Tue, 31 Aug 2004 11:30:45 -0500 To: pgman@candle.pha.pa.us X-Mailer: Apple Mail (2.619) X-Virus-Scanned: by amavisd-new at hub.org X-Spam-Status: No, hits=0.0 tagged_above=0.0 required=5.0 tests= X-Spam-Level: X-Archive-Number: 200408/56 X-Sequence-Number: 2516 Bruce, Considering the activity on the lists (at least recently and, I think, historically) about postgres not casting (usually integer) constant values across types, could there be a mention of this made in the FAQ? It seems like a logical case for inclusion under 4.8: http://www.postgresql.org/docs/faqs/FAQ.html#4.8 I was thinking something like the following: Also note that 7.x versions of postgres will not automatically cast constant data in certain queries such that an index would be used. For example, if you have the following: CREATE TABLE index_breaker ( bigintcol int8 primary key some_data text ); The following query is liikely to perform a sequential scan: SELECT some_data FROM index_breaker WHERE bigintcol = 42; postgres will interpret the constant value as a basic int and will thus not use the index (implicitly created by the primary key) on the bigintcol column. There are some workarounds for this issue [per Tom Lane]: 1. Always quote your constants: ... WHERE bigintcol = '42'; Similarly, constants can be explicitly cast: ... WHERE bigintcol = int8( 42 ) 2. Use a prepared statement: PREPARE foo(bigint) AS ... WHERE bigintcol = $1; EXECUTE foo(42); 3. Use parameterized statements in extended-query mode (essentially the same idea as #2, but at the protocol level). This doesn't help for pure SQL scripts, but is very workable when coding against libpq or JDBC. Among other things it gets you out of worrying about SQL injection attacks when your parameter values come from untrusted sources. Technical improvements to wording are welcome. But I think this is worth adding to the docs somewhere. Thanks! -tfo