Re: performance for high-volume log insertion - Mailing list pgsql-performance

From Stephen Frost
Subject Re: performance for high-volume log insertion
Date
Msg-id 20090423111132.GN8123@tamriel.snowman.net
Whole thread Raw
In response to Re: performance for high-volume log insertion  (Glenn Maynard <glennfmaynard@gmail.com>)
List pgsql-performance
* Glenn Maynard (glennfmaynard@gmail.com) wrote:
> I'd suggest this be mentioned in the sql-prepare documentation, then,
> because that documentation only discusses using prepared statements to
> eliminate redundant planning costs.  (I'm sure it's mentioned in the
> API docs and elsewhere, but if it's a major intended use of PREPARE,
> the PREPARE documentation should make note of it.)

Argh.  Perhaps the problem is that it's somewhat 'overloaded'.  PG
supports *both* SQL-level PREPARE/EXECUTE commands and the more
traditional (well, in my view anyway...) API/protocol of PQprepare() and
PQexecPrepared().  When using the API/protocol, you don't actually
explicitly call the SQL 'PREPARE blah AS INSERT INTO', you just call
PQprepare() with 'INSERT INTO blah VALUES ($1, $2, $3);' and then call
PQexecPrepared() later.

That's the reason it's not documented in the SQL-level PREPARE docs,
anyway.  I'm not against adding some kind of reference there, but it's
not quite the way you think it is..

    Thanks,

        Stephen

Attachment

pgsql-performance by date:

Previous
From: Stephen Frost
Date:
Subject: Re: performance for high-volume log insertion
Next
From: "John L. Clark"
Date:
Subject: Re: WHERE condition not being pushed down to union parts