Received: from localhost (unknown [200.46.204.183]) by mail.postgresql.org (Postfix) with ESMTP id C94AC64FCC4 for ; Mon, 10 Nov 2008 02:50:52 -0400 (AST) Received: from mail.postgresql.org ([200.46.204.86]) by localhost (mx1.hub.org [200.46.204.183]) (amavisd-maia, port 10024) with ESMTP id 86452-02 for ; Mon, 10 Nov 2008 02:50:52 -0400 (AST) X-Greylist: domain auto-whitelisted by SQLgrey-1.7.6 Received: from fg-out-1718.google.com (fg-out-1718.google.com [72.14.220.154]) by mail.postgresql.org (Postfix) with ESMTP id 2D00D64FC12 for ; Mon, 10 Nov 2008 02:50:52 -0400 (AST) Received: by fg-out-1718.google.com with SMTP id 16so2269926fgg.23 for ; Sun, 09 Nov 2008 22:50:50 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:received:received:message-id:date:from :user-agent:mime-version:to:subject:content-type :content-transfer-encoding; bh=InCgTHQckhkpBVxWe3DnRNmDbll8s2J7svyyI6ocNsY=; b=YD+N0Ckcy8fCOSexhMomTeMjpe4+YeTL4y+v43uP8QeFlS6N/KbCylL2uqjVCtYJN2 erlE41ZRClA1vqJ7M1bQerTYhNyuZ106PahuEgbijaHodEYpZZTGVIMPhddj3C2qfkNb l3l7zV7QD9qBvVvSggMbz457kzEdBLUGa0oN4= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=message-id:date:from:user-agent:mime-version:to:subject :content-type:content-transfer-encoding; b=X20b/DCqDQee54thFvbRuKFrcyn/RRQJp6ntZfmEmmfPwPMdjZHO1ncIJOBKJXSPp/ giZfw7/WYWNQgMGxH6U4NArn8wKiLcOsZsDbhEdvLc8thasbdcjnXI7cY6XL6RjzfQbq pFv86c7f8e3tnlL9W1mulaShMIXV5G/Fjbvq8= Received: by 10.103.243.9 with SMTP id v9mr3461877mur.5.1226299850548; Sun, 09 Nov 2008 22:50:50 -0800 (PST) Received: from ?94.27.175.97? (gprs5e1baf61.pool.t-umts.hu [94.27.175.97]) by mx.google.com with ESMTPS id y6sm29262635mug.7.2008.11.09.22.50.47 (version=TLSv1/SSLv3 cipher=RC4-MD5); Sun, 09 Nov 2008 22:50:49 -0800 (PST) Message-ID: <4917D9C3.9060001@gmail.com> Date: Mon, 10 Nov 2008 07:50:43 +0100 From: =?ISO-8859-2?Q?Lutisch=E1n_Ferenc?= User-Agent: Thunderbird 2.0.0.17 (Windows/20080914) MIME-Version: 1.0 To: pgsql-performance@postgresql.org Subject: Improve Seq scan performance Content-Type: text/plain; charset=ISO-8859-2; format=flowed Content-Transfer-Encoding: 7bit X-Archive-Number: 200811/50 X-Sequence-Number: 31781 Dear List, I would like to improve seq scan performance. :-) I have many cols in a table. I use only 1 col for search on it. It is indexed with btree with text_pattern_ops. The search method is: r like '%aaa%' When I make another table with only this col values, the search time is better when the data is cached. But wronger when the data isn't in cache. I think the following: - When there is a big table with many cols, the seq search is read all cols not only searched. - If we use an index with full values of a col, it is possible to seq scan over the index is make better performance (lower io with smaller data). It is possible to make an index on the table, and make a seq index scan on this values? Thanks for helping. Best Regards, Ferenc