Re: performance for high-volume log insertion
От | david@lang.hm |
---|---|
Тема | Re: performance for high-volume log insertion |
Дата | |
Msg-id | alpine.DEB.1.10.0904211709030.12662@asgard.lang.hm обсуждение исходный текст |
Ответ на | Re: performance for high-volume log insertion (Stephen Frost <sfrost@snowman.net>) |
Ответы |
Re: performance for high-volume log insertion
Re: performance for high-volume log insertion |
Список | pgsql-performance |
On Tue, 21 Apr 2009, Stephen Frost wrote: > * James Mansion (james@mansionfamily.plus.com) wrote: >> david@lang.hm wrote: >>> on the other hand, when you have a full queue (lots of stuff to >>> insert) is when you need the performance the most. if it's enough of a >>> win on the database side, it could be worth more effort on the >>> applicaiton side. >> Are you sure preparing a simple insert is really worthwhile? >> >> I'd check if I were you. It shouldn't take long to plan. > > Using prepared queries, at least if you use PQexecPrepared or > PQexecParams, also reduces the work required on the client to build the > whole string, and the parsing overhead on the database side to pull it > apart again. That's where the performance is going to be improved by > going that route, not so much in eliminating the planning. 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? David Lang
В списке pgsql-performance по дате отправления: