On 09/28/2016 05:39 PM, Robert Haas wrote:
On Tue, Sep 27, 2016 at 5:15 PM, Tomas Vondra
wrote:
So, I got the results from 3.10.101 (only the pgbench data), and it looks
like this:
3.10.101 1 8 16 32 64128192
-
On 9/28/16 3:35 AM, Michael Paquier wrote:
> On Wed, Sep 28, 2016 at 6:12 AM, David Steele wrote:
>> I tried the attached patch set and noticed an interesting behavior. With
>> archive_timeout=5 whenever I made a change I would get a WAL segment within
>> a few seconds as expected then another one
On Wed, Sep 28, 2016 at 10:48 AM, Robert Haas wrote:
> On Sun, Sep 25, 2016 at 3:28 PM, Tomas Vondra
> wrote:
> > Sure, that would be useful.
> >
> > I think it would be useful to make repository of such data sets, so that
> > patch authors & reviewers can get a reasonable collection of data set
Hello everyone, patch was rebased.
Thank you Tomas for your reviewing this patch and for your valuable
comments.
From the very beginning we had the misunderstanding with the naming of
meethods.
> It'd be really useful if you could provide actual numbers, explain what
> metrics you compare a
On 28 Sep. 2016 17:50, "valeriof" wrote:
>
> Hi all,
> I'm developing a custom plugin to stream Postgres CDC changes to my client
> application. One of the info the application needs is the user id of the
> user who executed a certain transaction. I can see we have access to other
> transaction in
On Wed, Sep 28, 2016 at 6:45 PM, Tomas Vondra
wrote:
> So, is 300 too little? I don't think so, because Dilip saw some benefit from
> that. Or what scale factor do we think is needed to reproduce the benefit?
> My machine has 256GB of ram, so I can easily go up to 15000 and still keep
> everything
On Wed, Sep 28, 2016 at 3:04 PM, Robert Haas wrote:
> I'll write another email with my thoughts about the rest of the patch.
I think that the README changes for this patch need a fairly large
amount of additional work. Here are a few things I notice:
- The confusion between buckets and pages ha
On 09/29/2016 01:59 AM, Robert Haas wrote:
On Wed, Sep 28, 2016 at 6:45 PM, Tomas Vondra
wrote:
So, is 300 too little? I don't think so, because Dilip saw some benefit from
that. Or what scale factor do we think is needed to reproduce the benefit?
My machine has 256GB of ram, so I can easily go
On Wed, Sep 28, 2016 at 9:45 PM, Robert Haas wrote:
> On Wed, Sep 28, 2016 at 8:38 AM, Michael Paquier
> wrote:
>> So should I change back the patch to have only one argument for the
>> eventId, and guess classId from it?
>
> Why would you need to guess?
Incorrect wording from me perhaps? i just
On 9/25/16 8:06 AM, Ashutosh Sharma wrote:
> Hi Peter,
>
>> I just wanted to update you, I have taken this commit fest entry patch
>> to review because I think it will be addresses as part of "Exclude
>> additional directories in pg_basebackup", which I'm also reviewing.
>> Therefore, I'm not actu
On 9/28/16 2:45 AM, Michael Paquier wrote:
> After all that fixed, I have moved the patch to "Ready for Committer".
> Please use the updated patch though.
Committed after some cosmetic changes.
--
Peter Eisentraut http://www.2ndQuadrant.com/
PostgreSQL Development, 24x7 Support, Rem
On 9/28/16 6:07 PM, Alvaro Herrera wrote:
> Adopting a default prefix is a different question.
A default prefix would require different settings for syslog, plain
text, and possibly some of the other variants. I'm all in favor of
figuring that out, but it needs more work.
--
Peter Eisentraut
On 9/28/16 6:13 PM, Robert Haas wrote:
> Christoph/Debian:
> log_line_prefix = '%t [%p-%l] %q%u@%d '
> Peter:
> log_line_prefix = '%t [%p]: [%l] %qapp=%a '
I'm aware of two existing guidelines on log line formats: syslog and
pgbadger. Syslog output looks like this:
Sep 28 00:58:56 hostna
On Thu, Sep 29, 2016 at 7:45 AM, David Steele wrote:
> OK, I've done functional testing and this patch seems to work as
> specified (including the caveat noted above). Some comments:
Thanks!
> * [PATCH 1/3] hs-checkpoints-v12-1
>
> +++ b/src/backend/access/transam/xlog.c
> +* Taking a l
On Mon, Sep 26, 2016 at 10:57 AM, Thomas Munro
wrote:
> On Thu, Sep 1, 2016 at 1:41 AM, Peter Eisentraut
> wrote:
>>
>> [trimmed cc list because of big attachments]
>>
>> On 8/16/16 4:22 PM, Jim Nasby wrote:
>> > Joy, do you have an idea what a *minimally invasive* patch for C++
>> > support woul
Peter Eisentraut writes:
> On 9/28/16 6:13 PM, Robert Haas wrote:
>> Christoph/Debian:
>> log_line_prefix = '%t [%p-%l] %q%u@%d '
>> Peter:
>> log_line_prefix = '%t [%p]: [%l] %qapp=%a '
> ...
> I don't know why it wants that "-1" there, and I'm actually not sure
> what the point of %l is in prac
On 27 September 2016 at 15:15, Jeevan Chalke
wrote:
> Hello Stephen,
>
> On Tue, Sep 27, 2016 at 12:57 AM, Stephen Frost wrote:
>>
>> Jeevan,
>>
>> * Jeevan Chalke (jeevan.cha...@enterprisedb.com) wrote:
>> > I have started reviewing this patch and here are couple of points I have
>> > observed s
On Wed, Sep 28, 2016 at 11:25 PM, Konstantin Knizhnik
wrote:
> But if table was just altered and some attribute was removed from the table,
> then rel->natts can be greater than natts.
This is part of pglogical, so you may want to reply on the dedicated
thread or send directly a patch to them. By
On Wed, Sep 28, 2016 at 8:55 PM, Michael Paquier
wrote:
>> Our b64_encode routine does use whitespace, so we can't use it as is for
>> SCRAM. As the patch stands, we might never output anything long enough to
>> create linefeeds, but let's be tidy. The base64 implementation is about 100
>> lines o
On Fri, Sep 16, 2016 at 10:36 PM, Michael Paquier
wrote:
> On Fri, Sep 16, 2016 at 10:30 PM, Robert Haas wrote:
>> I don't think you have the right to tell Kuntal that he has to move
>> the patch to the next CommitFest because there are unspecified things
>> about the current version you don't li
On Thu, Sep 29, 2016 at 2:25 AM, Robert Haas wrote:
> So, anyone else have an opinion, pro or con?
Going through this thread, I'd vote -1. This is a documentation effort
mainly, and installing those files has zero effect if they are not
loaded via include_if_exists or include in postgresql.conf.
On 29/09/16 05:33, Michael Paquier wrote:
> On Wed, Sep 28, 2016 at 11:25 PM, Konstantin Knizhnik
> wrote:
>> But if table was just altered and some attribute was removed from the table,
>> then rel->natts can be greater than natts.
>
> This is part of pglogical, so you may want to reply on the d
On Thu, Sep 29, 2016 at 11:12:11AM +1300, Thomas Munro wrote:
> On Mon, Sep 26, 2016 at 5:11 PM, Thomas Munro
> wrote:
> > On Mon, Sep 26, 2016 at 1:18 PM, Thomas Munro
> > wrote:
> >>
> >> On Mon, Sep 19, 2016 at 4:02 PM, David Fetter wrote:
> >> >
> >> > [training_wheels_004.patch]
> >>
> >> [
Sorry for delayed response, I'll have enough time from now and
address this.
At Fri, 23 Sep 2016 21:09:03 -0400, Robert Haas wrote
in
> Well, I promised to post this, so here it is. It's not really working
> all that well at this point, and it's definitely not doing anything
> that interesting
On Thu, Sep 22, 2016 at 3:05 AM, Alvaro Herrera
wrote:
> Peter Eisentraut wrote:
>
> > How about having the tag not be a column name but a row entry. So you'd
> > do something like
> >
> > SELECT * FROM pg_stat_sql WHERE tag = 'ALTER VIEW';
> >
> > That way, we don't have to keep updating (and r
On 09/29/2016 05:55 AM, Michael Paquier wrote:
> On Thu, Sep 29, 2016 at 2:25 AM, Robert Haas wrote:
>> So, anyone else have an opinion, pro or con?
>
> Going through this thread, I'd vote -1. This is a documentation effort
> mainly, and installing those files has zero effect if they are not
> lo
Hello, thank you for the comment.
At Wed, 28 Sep 2016 10:00:08 +0530, Amit Khandekar
wrote in
> On 24 September 2016 at 06:39, Robert Haas wrote:
> > Since Kyotaro Horiguchi found that my previous design had a
> > system-wide performance impact due to the ExecProcNode changes, I
> > decided to
Hello,
At Wed, 28 Sep 2016 12:49:25 -0400, Robert Haas wrote
in
> This patch hasn't been updated in over a week and we're just about out
> of time for this CommitFest, so I've marked it "Returned with
> Feedback" for now. If it gets updated, it can be resubmitted for the
> next CommitFest.
Th
On Thu, Sep 29, 2016 at 12:07 AM, Pavel Stehule
wrote:
> Hi
>
> 2016-09-28 18:57 GMT+02:00 Tom Lane :
>
>> Pavel Stehule writes:
>> > 2016-09-28 16:03 GMT+02:00 Tom Lane :
>> >> I propose to push my current patch (ie, move PL function
>> >> source code to \df+ footers), and we can use it in HEAD
On Sat, Aug 6, 2016 at 3:00 AM, Jeff Janes wrote:
> One time too many, I ran some minor change using psql on a production
> server and was wondering why it was taking so much longer than it did
> on the test server. Only to discover, after messing around with
> opening new windows and running qu
101 - 130 of 130 matches
Mail list logo
