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
|
Список | 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 по дате отправления: