Message-ID: <4FE1D365.2010204@squeakycode.net>
Date: Wed, 20 Jun 2012 08:43:01 -0500
From: Andy Colson <andy@squeakycode.net>
User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64;
	rv:13.0) Gecko/20120614 Thunderbird/13.0.1
MIME-Version: 1.0
To: Eyal Wilde <eyal@impactsoft.co.il>
CC: pgsql-performance@postgresql.org
Subject: Re: scale up (postgresql vs mssql)
References: 
 <CAMiEbcjn4UQcsk=NSNmE4rbAE2TwLBviUGYOZmXFK5mYyHVu+A@mail.gmail.com>
In-Reply-To: 
 <CAMiEbcjn4UQcsk=NSNmE4rbAE2TwLBviUGYOZmXFK5mYyHVu+A@mail.gmail.com>
Content-Type: text/plain; charset=UTF-8; format=flowed
Content-Transfer-Encoding: 7bit

On 6/20/2012 1:01 AM, Eyal Wilde wrote:
> Hi, all.
>
> this is an obligation from the past:
> http://archives.postgresql.org/pgsql-performance/2012-05/msg00017.php
>
> the same test, that did ~230 results, is now doing ~700 results. that
> is, BTW even better than mssql.
>
> the ultimate solution for that problem was to NOT to do "ON COMMIT
> DELETE ROWS" for the temporary tables. instead, we just do "DELETE FROM
> temp_table1".
>
> doing "TRUNCATE temp_table1" is defiantly the worst case (~100 results
> in the same test). this is something we knew for a long time, which is
> why we did "ON COMMIT DELETE ROWS", but eventually it turned out as far
> from being the best.
>
> another minor issue is that when configuring
>   temp_tablespace='other_tablespace', the sequences of the temporary
> tables remain on the 'main_tablespace'.
>
> i hope that will help making postgres even better :)
>

Did you ever try re-writing some of the temp table usage to use 
subselect's/views/cte/etc?

-Andy