Re: performance of temporary vs. regular tables

От: Joachim Worringen
Тема: Re: performance of temporary vs. regular tables
Дата: ,
Msg-id: 4C06547E.2010104@iathh.de
(см: обсуждение, исходный текст)
Ответ на: Re: performance of temporary vs. regular tables  ("Pierre C")
Ответы: Re: performance of temporary vs. regular tables  ("Pierre C")
Список: pgsql-performance

Скрыть дерево обсуждения

performance of temporary vs. regular tables  (Joachim Worringen, )
 Re: performance of temporary vs. regular tables  (Grzegorz Jaśkiewicz, )
  Re: performance of temporary vs. regular tables  (Joachim Worringen, )
   Re: performance of temporary vs. regular tables  (Thom Brown, )
    Re: performance of temporary vs. regular tables  (Joachim Worringen, )
     Re: performance of temporary vs. regular tables  (Grzegorz Jaśkiewicz, )
      Re: performance of temporary vs. regular tables  (Joachim Worringen, )
   Re: performance of temporary vs. regular tables  (Andres Freund, )
    Re: performance of temporary vs. regular tables  (Joachim Worringen, )
     Re: performance of temporary vs. regular tables  (Grzegorz Jaśkiewicz, )
     Re: performance of temporary vs. regular tables  (Joachim Worringen, )
      Re: performance of temporary vs. regular tables  (Rob Wultsch, )
      Re: performance of temporary vs. regular tables  ("Pierre C", )
       Re: performance of temporary vs. regular tables  (Joachim Worringen, )
        Re: performance of temporary vs. regular tables  ("Pierre C", )

Am 02.06.2010 12:03, schrieb Pierre C:
> Usually WAL causes a much larger performance hit than this.
>
> Since the following command :
>
> CREATE TABLE tmp AS SELECT n FROM generate_series(1,1000000) AS n
>
> which inserts 1M rows takes 1.6 seconds on my desktop, your 800k rows
> INSERT taking more than 3 minutes is a bit suspicious unless :
>
> - you got huge fields that need TOASTing ; in this case TOAST
> compression will eat a lot of CPU and you're benchmarking TOAST, not the
> rest of the system
> - you got some non-indexed foreign key
> - some other reason ?

Yes, the "other" reason is that I am not issueing a single SQL command,
but import data from plain ASCII files through the Pyhton-based
framework into the database.

The difference between your measurement and my measurent is the upper
potential of improvement for my system (which has, on the other hand,
the advantage of being a bit more powerful and flexible than a single
SQL statement....;-) )

  Joachim



В списке pgsql-performance по дате сообщения:

От: Wales Wang
Дата:
Сообщение: Re: File system choice for Red Hat systems
От: venu madhav
Дата:
Сообщение: Re: Autovacuum in postgres.