From: | Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us> |
---|---|
To: | Bruce Momjian <pgman(at)candle(dot)pha(dot)pa(dot)us> |
Cc: | Barry Lind <blind(at)xythos(dot)com>, Neil Conway <neilc(at)samurai(dot)com>, Hiroshi Inoue <Inoue(at)tpf(dot)co(dot)jp>, pgsql-hackers <pgsql-hackers(at)postgresql(dot)org> |
Subject: | Re: A bad behavior under autocommit off mode |
Date: | 2003-03-21 06:36:22 |
Message-ID: | 10584.1048228582@sss.pgh.pa.us |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-hackers |
Bruce Momjian <pgman(at)candle(dot)pha(dot)pa(dot)us> writes:
> Tom, did you have any thought of adding the ability to ask for reports
> on GUC variables on every query return?
That seems excessive. There is a case for reporting autocommit (if
we don't decide to remove it altogether, which is still an open
argument). I have not heard any complaints suggesting that we need any
others.
A fixed commitment to report xact status will cost us one byte added to
Z messages. If we add a commitment to report autocommit status, we
could choose to pack that bit into the same byte as xact status (still
only three bits used...). A slightly more forward-looking approach
would be to decree that Z messages carry labeled status bytes, ie, pairs
of <label> <status> bytes, which makes total cost 4 bytes to transmit
xact state and autocommit state. But if we want to say that we'll
transmit *any* darn random GUC variable you want to hear about, I don't
think we can use a compact encoding of this sort; instead we're talking
about sending the whole GUC variable name and string value as label and
value. In other words the Z message starts to look like
Z X a c t s t a t u s \0 i d l e \0 a u t o c o m m i t \0 o f f \0
and somewhere around here my concern for connection bandwidth kicks in.
A 10X increase in bytes sent is a bit much to cater to hypothetical
needs.
regards, tom lane
From | Date | Subject | |
---|---|---|---|
Next Message | Shridhar Daithankar<shridhar_daithankar@persistent.co.in> | 2003-03-21 06:45:13 | Fwd: Re: [GENERAL] Extracting time from timestamp |
Previous Message | Oleg Bartunov | 2003-03-21 06:31:36 | Re: [OpenFTS-general] New version of tsearch V2 ! |