Received: from localhost (maia-5.hub.org [200.46.204.182]) by postgresql.org (Postfix) with ESMTP id 7D32B9FA2FD for ; Sat, 16 Dec 2006 14:19:54 -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 75229-05 for ; Sat, 16 Dec 2006 14:19:42 -0400 (AST) X-Greylist: delayed 03:49:46.124208 by SQLgrey-1.7.4 Received: from smtp4.poczta.interia.pl (smtp10.poczta.interia.pl [80.48.65.10]) by postgresql.org (Postfix) with ESMTP id ADFCB9F9F47 for ; Sat, 16 Dec 2006 14:19:43 -0400 (AST) Received: by smtp4.poczta.interia.pl (INTERIA.PL, from userid 502) id 3B33027400A; Sat, 16 Dec 2006 19:19:42 +0100 (CET) Received: from poczta.interia.pl (mi01.poczta.interia.pl [10.217.12.1]) by smtp4.poczta.interia.pl (INTERIA.PL) with ESMTP id 297EE2740B1; Sat, 16 Dec 2006 19:19:41 +0100 (CET) Received: by poczta.interia.pl (INTERIA.PL, from userid 502) id E0C1927007D; Sat, 16 Dec 2006 19:19:40 +0100 (CET) Received: from [192.168.1.101] (nomad.net.autocom.pl [213.134.176.226]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by www.poczta.fm (INTERIA.PL) with ESMTP id AF935270077; Sat, 16 Dec 2006 19:19:39 +0100 (CET) Message-ID: <458438B9.5050103@poczta.fm> Date: Sat, 16 Dec 2006 19:19:37 +0100 From: jamcito User-Agent: Thunderbird 1.5.0.8 (X11/20061203) MIME-Version: 1.0 To: Tom Lane Cc: pgsql-performance@postgresql.org Subject: Re: partition text/varchar check problem -- solved References: <458402D4.7080500@poczta.fm> <29283.1166284128@sss.pgh.pa.us> In-Reply-To: <29283.1166284128@sss.pgh.pa.us> Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit X-EMID: 1d995138 X-Virus-Scanned: Maia Mailguard 1.0.1 X-Archive-Number: 200612/443 X-Sequence-Number: 22499 Tom Lane wrote: >> CREATE TABLE data_a (CHECK (name LIKE varchar 'a%') >> ) INHERITS (data); >> -- >> CREATE TABLE data_b (CHECK (name LIKE varchar 'b%') >> ) INHERITS (data); > > That's not going to work because the planner is unable to prove anything > about the behavior of LIKE --- there is nothing in the system that > offers a relationship between the = operator and the LIKE operator. > You'll need something like > > CHECK (name >= 'a' AND name < 'b') > CHECK (name >= 'b' AND name < 'c') > > etc. (These work for a query like "WHERE name = 'foo'" because > the >= < and = operators are all members of the same btree opclass, > so the planner knows how to reason about them.) > > regards, tom lane Thank you, it works! Cheers, jamcito ---------------------------------------------------------------------- Jestes kierowca? To poczytaj! >>> http://link.interia.pl/f199e