Re: performance for high-volume log insertion
От | Robert Haas |
---|---|
Тема | Re: performance for high-volume log insertion |
Дата | |
Msg-id | 603c8f070904211929o32dbe138ue7f1f1f32f2784c9@mail.gmail.com обсуждение исходный текст |
Ответ на | Re: performance for high-volume log insertion (david@lang.hm) |
Список | pgsql-performance |
On Tue, Apr 21, 2009 at 8:12 PM, <david@lang.hm> wrote: >> 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? Joins are expensive to plan; a simple insert is not. I also disagree that pre-parsed but not pre-planned is a waste of time, whoever said it. Sometimes it's what you want, especially in PL/pgsql. ...Robert
В списке pgsql-performance по дате отправления: