On Wed, May 04, 2005 at 10:22:56PM -0400, Tom Lane wrote:
> Also, there is a whole lot of one-time-per-statement overhead that can
> be amortized across many rows instead of only one. Stuff like opening
> the target table, looking up the per-column I/O conversion functions,
> identifying trigger f
Christopher Petrilli wrote:
On 5/4/05, Mischa Sandberg <[EMAIL PROTECTED]> wrote:
Quoting David Roussel <[EMAIL PROTECTED]>:
COPY invokes all the same logic as INSERT on the server side
(rowexclusive locking, transaction log, updating indexes, rules).
The difference is that all the rows are insert
> Should there not be at least one Index Scan showing in the stats?
not if there was a table scan
---(end of broadcast)---
TIP 8: explain analyze is your friend
Jona <[EMAIL PROTECTED]> writes:
> I'm currently experiencing problems with long query execution times.
> What I believe makes these problems particularly interesting is the
> difference in execution plans between our test server running PostGreSQL
> 7.3.6 and our production server running PostGr
Hi
I'm currently experiencing problems with long query execution times.
What I believe makes these problems particularly interesting is the
difference in execution plans between our test server running PostGreSQL
7.3.6 and our production server running PostGreSQL 7.3.9.
The test server is an upgr
On Wed, 4 May 2005, Mischa Sandberg wrote:
> Quoting Kris Jurka <[EMAIL PROTECTED]>:
>
> > Not true. A client may send any number of Bind/Execute messages on
> > a prepared statement before a Sync message.
> Hunh. Interesting optimization in the JDBC driver. I gather it is
> sending a str
