the PGconn buffer to the PGresult
structure to their buffers. The callback keeps the slowest guy on the
team...on the bench.
Kyle Gearhart
--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-hackers
On 2/9/17 7:15 PM, Jim Nasby wrote:
> Can you run a trace to see where all the time is going in the single row
> case? I don't see an obvious time-suck with a quick look through the code.
> It'd be interesting to see how things change if you eliminate the filler
> column from the SELECT.
Traces
From: Tom Lane [mailto:t...@sss.pgh.pa.us]:
> Kyle Gearhart writes:
>> The guts of pqRowProcessor in libpq does a good bit of work to maintain the
>> internal data structure of a PGresult. There are a few use cases where the
>> caller doesn't need the ability to ac
QrowProcessorCB)(PGresult*, const PGdataValue*, int col_count, void
*user_data);
My initial testing shows a significant performance improvement. I'd like some
opinions on this before wiring up a performance proof and updating the
documentation for a formal patch submission.
Kyle Gearhart
'd want to compress before putting it on the wire anyway.
If this is remotely possible let me know, I might be interested in
taking a look at it.
-Kyle
Bruce Momjian wrote:
>
> I am not excited about per-db/user compression because of the added
> complexity of setting it up, and even set u
6:33.31
the differences in read times are basically in the mud. Blocksize
just doesn't matter much with the kernel doing readahead.
-Kyle
---(end of broadcast)---
TIP 6: Have you searched our list archives?
http://archives.postgresql.org
Greg Copeland wrote:
> [cut]
> My current thoughts are to allow for enabled/disabled compression and
> variable compression settings (1-9) within a database configuration.
> Worse case, it may be fun to implement and I'm thinking there may
> actually be some surprises as an end result if it's don
On the subject on client/server compression, does the server
decompress toast data before sending it to the client? Is so, why
(other than requiring modifications to the protocol)?
On the flip side, does/could the client toast insert/update data
before sending it to the server?
-Kyle
On Tue, Apr 17, 2001 at 09:11:54AM -0400, Peter T Mount wrote:
> Erm, int8 isn't long, but an array of 8 int's (unless it's changed).
http://postgresql.readysetnet.com/users-lounge/docs/7.0/user/datatype.htm#AEN942
It is very much an 8-byte integer, the correlary to Java'
lly big warning missing
> > from the documentation!
>
> Ah, it just dawned on me what might be happening: Peter, I'm guessing
> that you are thinking of "INT48" or some such, the pseudo-integer array
> type. Kyle is referring to the "int8" 8 byte integer type.
On Tue, Apr 10, 2001 at 02:24:24PM +0100, Peter Mount wrote:
> At 18:30 09/04/01 -0700, Kyle VanderBeek wrote:
> >This is a new feature? Using indecies is "new"? I guess I really beg to
> >differ. Seems like a bugfix to me (in the "workaround" category
patch already?
>
> Again not JDBC. Forwarding to the hackers list on this one. The naming
> conventions were changed a lot in 7.1, and it was for more flexability.
Right, cool. I'll check out the new codebase. Thanks.
This is *so* the curse of open source: now I'm going
12 matches
Mail list logo
