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 up, I can see cases where
with the kernel doing readahead.
-Kyle
---(end of broadcast)---
TIP 6: Have you searched our list archives?
http://archives.postgresql.org
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
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 done
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).
Yes they are. INT8 i
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.
Yes!
I guess I'm asking this: I've got an enterprise da
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's Long/long.
--
Kyle
)(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
--
Sent via pgsql
From: Tom Lane [mailto:t...@sss.pgh.pa.us]:
> Kyle Gearhart <kyle.gearh...@indigohill.io> 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
>> call
n 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.
11 matches
Mail list logo
