Re: performance for high-volume log insertion

Поиск
Список
Период
Сортировка
От Stephen Frost
Тема Re: performance for high-volume log insertion
Дата
Msg-id 20090422121928.GF8123@tamriel.snowman.net
обсуждение исходный текст
Ответ на Re: performance for high-volume log insertion  (david@lang.hm)
Ответы Re: performance for high-volume log insertion  (Glenn Maynard <glennfmaynard@gmail.com>)
Список pgsql-performance
David,

* david@lang.hm (david@lang.hm) wrote:
> in a recent thread about prepared statements, where it was identified
> that since the planning took place at the time of the prepare you
> sometimes have worse plans than for non-prepared statements, a proposal
> was made to have a 'pre-parsed, but not pre-planned' version of a
> prepared statement. This was dismissed as a waste of time (IIRC by Tom L)
> as the parsing time was negligable.
>
> was that just because it was a more complex query to plan?

Yes, as I beleive was mentioned already, planning time for inserts is
really small.  Parsing time for inserts when there's little parsing that
has to happen also isn't all *that* expensive and the same goes for
conversions from textual representations of data to binary.

We're starting to re-hash things, in my view.  The low-hanging fruit is
doing multiple things in a single transaction, either by using COPY,
multi-value INSERTs, or just multiple INSERTs in a single transaction.
That's absolutely step one.

Adding in other things, where they make sense (prepared statements,
binary format for things you have as binary, etc) is a good idea if it
can be done along the way.

    Stephen

Вложения

В списке pgsql-performance по дате отправления:

Предыдущее
От: roopabenzer
Дата:
Сообщение: Re: probelm with alter table add constraint......
Следующее
От: Stephen Frost
Дата:
Сообщение: Re: performance for high-volume log insertion