writes packet - Search results in mailing lists
Mailing lists >> pgsql-performance >> Thread
2021-11-17 17:51:05 | Re: Need help identifying a periodic performance issue. (Robert Creager)
write=795.559 s, sync=0.018 s, total=795.647 s; sync files=59, longest=0.018 s, average=0.001 s; distance=33884 kB, estimate=179063 kB Nov 17 06:53:07 sm2u-10 postgres
Mailing lists >> pgsql-performance >> Thread >> Search in thread (4)
2021-06-15 17:22:23 | Re: waiting for client write (Vijaykumar Jain)
write. I think i might have to intentionally mangle some response packets from server to client
Mailing lists >> pgsql-performance >> Thread
2021-04-16 13:27:38 | Re: Why is there a tenfold difference between Postgres's alleged query execution time and (Tom Lane)
Rollo Konig-Brock
Mailing lists >> pgsql-performance >> Thread
2010-01-05 01:14:22 | Re: pg_connect takes 3.0 seconds (Tom Lane)
writes: Sounds a lot like a dropped-packets problem. The exact timing would be explained
Mailing lists >> pgsql-performance >> Thread
2009-07-15 12:30:53 | Re: [BUGS] BUG #4919: CREATE USER command slows down system performance (Tom Lane)
writes: Yeah, but even with the current setup, an attacker who can fire connection request packets
Mailing lists >> pgsql-performance >> Thread
2009-04-21 05:26:30 | Re: performance for high-volume log insertion (david@lang.hm)
write the log message to disk) if we stick with the string based API we never need to the user gives us one string 'prepare...' that we send to the database. the user then gives
Mailing lists >> pgsql-performance >> Thread
2009-02-23 15:42:20 | Re: TCP network cost (Ross J. Reedstrom)
packet-acked stairstep of a delayed-ack/Nagle interaction. (as described here: http:///papers/NagleDelayedAck/ ) Walking through the libpq code, though, it sets NODELAY, so Nagle should be out of the picture. This
Mailing lists >> pgsql-performance >> Thread
2007-06-21 22:51:41 | Re: Data transfer very slow when connected via DSL (Tom Lane)
writes: Hm, but surely you can get it to fetch more than one row at once? This previous post says that someone else solved an ODBC performance problem with UseDeclareFetch=1: http:///pgsql-odbc/2006-08/msg00014.php
Mailing lists >> pgsql-performance >> Thread >> Search in thread (2)
2007-05-25 05:51:12 | general PG network slowness (possible cure) (repost) (Peter T. Breuer)
write a network server for gdbm databases, and talk to _that_ just to get a comparison. Lo and behold and smack me with a corncob if it wasn't _slower_ than pg. On a whim
Mailing lists >> pgsql-performance >> Thread
2007-03-13 13:02:33 | Re: Postgres batch write very slow - what to do (Tom Lane)
writes: Perhaps a bit of checking with a packet sniffer would be warranted. If it's really
Mailing lists >> pgsql-performance >> Thread >> Search in thread (2)
2006-12-11 11:59:11 | Re: Low throughput of binary inserts from windows to linux (Tom Lane)
writes: Yeah, that's what I couldn't think of the other day. The principal report was here: http:///pgsql-general/2005-01/msg01231.php By default, Windows XP installs the QoS Packet
Mailing lists >> pgsql-performance >> Thread
2006-05-18 16:38:36 | Re: why is bitmap index chosen for this query? (Stephen Byers)
packets where environment_name='PASITCTX01' and system_time_secs>=1132272000 and system_time_secs<=1143244800; fetch 10 from myCursor; end; PS, this is on a Sun Fire V240 with 4GB RAM, Solaris 8. Thanks, Steve
Mailing lists >> pgsql-performance >> Thread
2005-09-12 19:02:32 | Re: Performance considerations for very heavy INSERT traffic (Brandon Black)
packet back to the client on transaction success/failure. The aggregator could put several clients' data into a series of delayed multi-row copy statements. - using Bizgres ? I only briefly scanned their "About" page, but they
Mailing lists >> pgsql-performance >> Thread
2005-07-25 19:39:59 | COPY insert performance (Chris Isaacson)
WRITE AHEAD LOG #----------------------------------------------------------------------- ---- fsync = false # turns forced synchronization on or off wal_buffers = 64 # min 4, 8KB each checkpoint_segments = 40 # in logfile segments, min 1, 16MB each checkpoint_timeout = 600 # range 30-3600
Mailing lists >> pgsql-performance >> Thread >> Search in thread (2)
2005-04-13 00:27:38 | Re: [NOVICE] Many connections lingering (Greg Stark)
writes: No, what Tom's describing is a different pair of states called FIN_WAIT_1 and FIN_WAIT_2. TIME_WAIT isn't waiting for a packet