Re: performance of temporary vs. regular tables - Mailing list pgsql-performance

From Rob Wultsch
Subject Re: performance of temporary vs. regular tables
Date
Msg-id AANLkTinmMF0ZXWYmfIuIx4BESK7-RvvjOSDu0dchkeM7@mail.gmail.com
Whole thread Raw
In response to Re: performance of temporary vs. regular tables  (Joachim Worringen <joachim.worringen@iathh.de>)
List pgsql-performance
On Fri, May 28, 2010 at 4:04 AM, Joachim Worringen
<joachim.worringen@iathh.de> wrote:
> On 05/26/2010 06:03 PM, Joachim Worringen wrote:
>>
>> Am 25.05.2010 12:41, schrieb Andres Freund:
>>>
>>> On Tuesday 25 May 2010 11:00:24 Joachim Worringen wrote:
>>>>
>>>> Thanks. So, the Write-Ahead-Logging (being used or not) does not matter?
>>>
>>> It does matter quite significantly in my experience. Both from an io
>>> and a cpu
>>> overhead perspective.
>>
>> O.k., looks as if I have to make my own experience... I'll let you know
>> if possible.
>
> As promised, I did a tiny benchmark - basically, 8 empty tables are filled
> with 100k rows each within 8 transactions (somewhat typically for my
> application). The test machine has 4 cores, 64G RAM and RAID1 10k drives for
> data.
>
> # INSERTs into a TEMPORARY table:
> [joachim@testsrv scaling]$ time pb query -d scaling_qry_1.xml
>
> real    3m18.242s
> user    1m59.074s
> sys     1m51.001s
>
> # INSERTs into a standard table:
> [joachim@testsrv scaling]$ time pb query -d scaling_qry_1.xml
>
> real    3m35.090s
> user    2m5.295s
> sys     2m2.307s
>
> Thus, there is a slight hit of about 10% (which may even be within
> meausrement variations) - your milage will vary.
>
>  Joachim
>
>
> --
> Sent via pgsql-performance mailing list (pgsql-performance@postgresql.org)
> To make changes to your subscription:
> http://www.postgresql.org/mailpref/pgsql-performance
>
I think it would be interesting to create a ram disk and insert into
it. In the MySQL community even thought MyISAM has fallen out of use
the Memory table (based on MyISAM) is still somewhat used.


--
Rob Wultsch
wultsch@gmail.com

pgsql-performance by date:

Previous
From: Merlin Moncure
Date:
Subject: Re: PostgreSQL Function Language Performance: C vs PL/PGSQL
Next
From: Thom Brown
Date:
Subject: Wildly inaccurate query plan