Sorry missed to keep -hackers in previous mail.
From: Amit Kapila
Date: Mon, Oct 7, 2013 at 11:37 AM
Subject: Re: Patch for reserved connections for replication users
To: Robert Haas , gibh...@zero-knowledge.org
Cc: Andres Freund , ma...@joh.to
Robert Haas wrote:
On Mon, Aug 5, 2013 at 2:04 AM,
On Fri, Oct 4, 2013 at 11:35 PM, Bruce Momjian wrote:
> On Fri, Oct 4, 2013 at 10:19:38AM +, Haribabu kommi wrote:
> >
> > On 03 October 2013 19:30 Bruce Momjian wrote:
> > >On Thu, Oct 3, 2013 at 11:54:14AM +0530, Rushabh Lathia wrote:
> > >> Thanks Bruce.
> > >>
> > >> Yes for me main pro
On Thu, Oct 3, 2013 at 10:46:05AM -0700, Kevin Grittner wrote:
> > opcname
> > -
> > varchar_ops
> > kd_point_ops
> > cidr_ops
> > text_pattern_ops
> > varchar_pattern_ops
> > bpchar_pattern_ops
> > (6 rows)
> >
> > Do these all have op
On 6.10.2013 20:37, Tomáš Janoušek wrote:
> Hi,
>
> On Sat, Oct 05, 2013 at 08:22:54PM +0200, Tomas Vondra wrote:
>> I'm on 64-bit architecture and the example works with int32, which means
>> the sizes should be about this:
>>
>> hash_element_t => 20B
>> hash_bucket_t => 4B + (20B * item
2013/9/10 Ronan Dunklau :
> For row-level triggers, it seems more complicated. From what I understand,
> OLD/NEW tuples are fetched from the heap using their ctid (except for BEFORE
> INSERT triggers). How could this be adapted for foreign tables ?
>
It seems to me the origin of difficulty to suppo
Hi,
On Sat, Oct 05, 2013 at 08:22:54PM +0200, Tomas Vondra wrote:
> I'm on 64-bit architecture and the example works with int32, which means
> the sizes should be about this:
>
> hash_element_t => 20B
> hash_bucket_t => 4B + (20B * items in the bucket [in steps of 5])
> hash_table_t
On Sun, Oct 06, 2013 at 06:44:11PM +0200, Fabien COELHO wrote:
> >>>Patch (2): Make --initialize mode respect --progress.
> >>>Rejected
> >>
> >>I missed this one...
> >
> >See the second half of this message, including quoted material:
> >http://www.postgresql.org/message-id/CA+TgmoZNXkm-EtszHX=kw
Kevin Grittner wrote:
> Kevin Grittner wrote:
>
>> I'm strongly leaning toward the idea that a slightly tweaked
>> version of the proposed patch is appropriate for the back-branches,
>> because the fix Heikki is now suggesting seems too invasive to
>> back-patch. I think it would make sense to a
Patch (2): Make --initialize mode respect --progress.
Rejected
I missed this one...
See the second half of this message, including quoted material:
http://www.postgresql.org/message-id/CA+TgmoZNXkm-EtszHX=kwq34h5ni4cs8dg31no86cmdryaq...@mail.gmail.com
I did not read Peter Haas comments as
On Sun, Oct 06, 2013 at 05:04:56PM +0200, Fabien COELHO wrote:
> > Patch (2): Make --initialize mode respect --progress.
> >Rejected
>
> I missed this one...
See the second half of this message, including quoted material:
http://www.postgresql.org/message-id/CA+TgmoZNXkm-EtszHX=kwq34h5ni4cs8dg31n
Hello Noah,
Patch (1): Change the default from --progress=0 to --progress=5
Rejected
Yep. Too bad, esp as the default is meaningless and does not scale.
Patch (2): Make --initialize mode respect --progress.
Rejected
I missed this one...
This is just about having the same option (--prog
On Sun, Oct 06, 2013 at 09:40:40AM +0200, Fabien COELHO wrote:
> Which part do you want as a next step?
I think we're done; here are the distinct changes in your original patch,
along with their dispositions:
Patch (1): Change the default from --progress=0 to --progress=5
Rejected
Patch (2)
On Sun, Oct 06, 2013 at 09:48:04AM +0200, Fabien COELHO wrote:
> Also, I'm not sure of any system used with pgbench that do not have
> threads, so ISTM that the thread fork-emulation hack is more or less
> useless, and it is pretty masochistic to maintain when adding
> features.
Fair point. When
On Sun, Oct 6, 2013 at 1:25 PM, Alvaro Herrera wrote:
> Michael Paquier escribió:
>
>> =# discard sequences ;
>> DISCARD SEQUENCES
>> =# select currval('foo');
>> ERROR: 55000: currval of sequence "foo" is not yet defined in this session
>> LOCATION: currval_oid, sequence.c:780
>> =# select last
Note that this is pretty standard stuff with threads, ISTM that it
would solve most of the issues, *but* this is not possible with the
"thread fork emulation" implemented by pgbench, which really means
no threads at all.
You could do those same things in the fork emulation mode using anonymous
Hello Noah,
Patch (4): Redefine "latency" as reported by pgbench and report "lag" more.
Here is a first partial patch, which focusses on measuring latency
and reporting the measure under --progress.
This patch contains the features pertaining to both hypothetical patches (3)
and (4), not ju
16 matches
Mail list logo
