Received: from malur.postgresql.org ([217.196.149.56]) by arkaria.postgresql.org with esmtp (Exim 4.80) (envelope-from ) id 1XUxbe-00022X-Fz for pgsql-performance@arkaria.postgresql.org; Fri, 19 Sep 2014 12:48:10 +0000 Received: from localhost ([127.0.0.1] helo=postgresql.org) by malur.postgresql.org with smtp (Exim 4.80) (envelope-from ) id 1XUxbd-0007kd-Vk for pgsql-performance@arkaria.postgresql.org; Fri, 19 Sep 2014 12:48:10 +0000 Received: from makus.postgresql.org ([2001:4800:1501:1::229]) by malur.postgresql.org with esmtps (TLS1.2:DHE_RSA_AES_256_CBC_SHA256:256) (Exim 4.80) (envelope-from ) id 1XUxbc-0007kS-OE for pgsql-performance@postgresql.org; Fri, 19 Sep 2014 12:48:08 +0000 Received: from mout.gmx.net ([212.227.17.22]) by makus.postgresql.org with esmtps (TLS1.2:DHE_RSA_AES_256_CBC_SHA256:256) (Exim 4.80) (envelope-from ) id 1XUxbZ-0006Cu-A4 for pgsql-performance@postgresql.org; Fri, 19 Sep 2014 12:48:07 +0000 Received: from [192.168.1.27] ([84.58.13.99]) by mail.gmx.com (mrgmx102) with ESMTPSA (Nemesis) id 0LtlG5-1YTtvb00n7-011852; Fri, 19 Sep 2014 14:48:02 +0200 Message-ID: <541C2603.5060203@gmx.de> Date: Fri, 19 Sep 2014 14:48:03 +0200 From: =?UTF-8?B?QmrDtnJuIFdpdHRpY2g=?= User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:24.0) Gecko/20100101 Thunderbird/24.6.0 MIME-Version: 1.0 To: Szymon Guz CC: "pgsql-performance@postgresql.org" Subject: Re: query a table with lots of coulmns References: <541C18C5.3080204@gmx.de> In-Reply-To: Content-Type: multipart/alternative; boundary="------------060207040102000808040502" X-Provags-ID: V03:K0:dR05Yun5mem9saCuavggyWr8cobOC3n+xVsRrMnMoYyJ5rPprlx NPuwIKzQa3FyyIzxHUfzRPEyn56dHNQZPYuBXdQJIorYkRKckUWRFdfTvfAb63jT6Dl0DFc XZFczR5KkLUU98tsHG9Y7Cccy2kV61B1WGpvVOtwgKr5uYi97O+hE5NRaQPNW1aSySRkLrb QapImbSnkB3Fg4IPNkxPw== X-UI-Out-Filterresults: notjunk:1; X-Pg-Spam-Score: -2.1 (--) List-Archive: List-Help: List-ID: List-Owner: List-Post: List-Subscribe: List-Unsubscribe: X-Mailing-List: pgsql-performance Precedence: bulk Sender: pgsql-performance-owner@postgresql.org This is a multi-part message in MIME format. --------------060207040102000808040502 Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 8bit Hi Szymon, yes I have indexes on both columns (one in each table) which I am using for join operation. Am 19.09.2014 14:04, schrieb Szymon Guz: > > > On 19 September 2014 13:51, Björn Wittich > wrote: > > Hi mailing list, > > I am relatively new to postgres. I have a table with 500 coulmns > and about 40 mio rows. I call this cache table where one column is > a unique key (indexed) and the 499 columns (type integer) are some > values belonging to this key. > > Now I have a second (temporary) table (only 2 columns one is the > key of my cache table) and I want do an inner join between my > temporary table and the large cache table and export all matching > rows. I found out, that the performance increases when I limit the > join to lots of small parts. > But it seems that the databases needs a lot of disk io to gather > all 499 data columns. > Is there a possibilty to tell the databases that all these colums > are always treated as tuples and I always want to get the whole > row? Perhaps the disk oraganization could then be optimized? > > Hi, > do you have indexes on the columns you use for joins? > > Szymon --------------060207040102000808040502 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: 8bit
Hi Szymon,

yes I have indexes on both columns (one in each table) which I am using for join operation.

Am 19.09.2014 14:04, schrieb Szymon Guz:


On 19 September 2014 13:51, Björn Wittich <Bjoern_Wittich@gmx.de> wrote:
Hi mailing list,

I am relatively new to postgres. I have a table with 500 coulmns and about 40 mio rows. I call this cache table where one column is a unique key (indexed) and the 499 columns (type integer) are some values belonging to this key.

Now I have a second (temporary) table (only 2 columns one is the key of my cache table) and I want  do an inner join between my temporary table and the large cache table and export all matching rows. I found out, that the performance increases when I limit the join to lots of small parts.
But it seems that the databases needs a lot of disk io to gather all 499 data columns.
Is there a possibilty to tell the databases that all these colums are always treated as tuples and I always want to get the whole row? Perhaps the disk oraganization could then be optimized?

 
Hi,
do you have indexes on the columns you use for joins?

Szymon

--------------060207040102000808040502--