On Fri, Sep 27, 2013 at 10:28 AM, Robert Haas wrote:
> On Thu, Sep 26, 2013 at 5:18 PM, Robert Haas
> wrote:
> > On Thu, Sep 26, 2013 at 3:55 PM, David Rowley
> wrote:
> >> I think I must have forgot to save it before I emailed it...
> >>
> >> Here's the correct version.
> >
> > Ah ha. Looks b
On Thu, Sep 26, 2013 at 5:18 PM, Robert Haas wrote:
> On Thu, Sep 26, 2013 at 3:55 PM, David Rowley wrote:
>> I think I must have forgot to save it before I emailed it...
>>
>> Here's the correct version.
>
> Ah ha. Looks better.
>
> I'm working on getting this committed now. Aside from some st
On Thu, Sep 26, 2013 at 3:55 PM, David Rowley wrote:
> I think I must have forgot to save it before I emailed it...
>
> Here's the correct version.
Ah ha. Looks better.
I'm working on getting this committed now. Aside from some stylistic
things, I've found one serious functional bug, which is
On Fri, Sep 27, 2013 at 4:44 AM, Robert Haas wrote:
> On Wed, Sep 25, 2013 at 4:46 AM, David Rowley
> wrote:
> > Ok, I think I've managed to narrow the performance gap to just about
> nothing
> > but noise, though to do this the code is now a bit bigger. I've added a
> > series of tests to see i
On Wed, Sep 25, 2013 at 4:46 AM, David Rowley wrote:
> Ok, I think I've managed to narrow the performance gap to just about nothing
> but noise, though to do this the code is now a bit bigger. I've added a
> series of tests to see if the padding is > 0 and if it's not then I'm doing
> things the o
On Thu, Sep 26, 2013 at 4:57 AM, Peter Eisentraut wrote:
> On 9/25/13 4:46 AM, David Rowley wrote:
> > Please find attached the new patch ... version v0.5 and also updated
> > benchmark results.
>
> Please fix compiler warnings:
>
> elog.c: In function ‘log_line_prefix.isra.3’:
> elog.c:2436:22:
On 9/25/13 4:46 AM, David Rowley wrote:
> Please find attached the new patch ... version v0.5 and also updated
> benchmark results.
Please fix compiler warnings:
elog.c: In function ‘log_line_prefix.isra.3’:
elog.c:2436:22: warning: ‘padding’ may be used uninitialized in this function
[-Wmaybe-u
On Wed, Sep 25, 2013 at 1:20 AM, Robert Haas wrote:
> On Tue, Sep 24, 2013 at 5:04 AM, David Rowley
> wrote:
> >> So... I guess the question that I'd ask is, if you write a PL/pgsql
> >> function that does RAISE NOTICE in a loop a large number of times, can
> >> you measure any difference in how
On Wed, Sep 25, 2013 at 6:25 AM, Andres Freund wrote:
> On 2013-09-24 19:56:32 +0200, Andres Freund wrote:
> > On 2013-09-24 13:51:04 -0300, Alvaro Herrera wrote:
> > > David Rowley escribió:
> > >
> > > > I do see a 15-18% slow down with the patched version, so perhaps
> I'll need
> > > > to look
On 2013-09-24 19:56:32 +0200, Andres Freund wrote:
> On 2013-09-24 13:51:04 -0300, Alvaro Herrera wrote:
> > David Rowley escribió:
> >
> > > I do see a 15-18% slow down with the patched version, so perhaps I'll need
> > > to look to see if I can speed it up a bit, although I do feel this
> > > be
On 2013-09-24 13:51:04 -0300, Alvaro Herrera wrote:
> David Rowley escribió:
>
> > I do see a 15-18% slow down with the patched version, so perhaps I'll need
> > to look to see if I can speed it up a bit, although I do feel this
> > benchmark is not quite a normal workload.
>
> Ouch. That's cert
David Rowley escribió:
> I do see a 15-18% slow down with the patched version, so perhaps I'll need
> to look to see if I can speed it up a bit, although I do feel this
> benchmark is not quite a normal workload.
Ouch. That's certainly way too much. Is the compiler inlining
process_log_prefix_p
On Tue, Sep 24, 2013 at 5:04 AM, David Rowley wrote:
>> So... I guess the question that I'd ask is, if you write a PL/pgsql
>> function that does RAISE NOTICE in a loop a large number of times, can
>> you measure any difference in how fast that function executes on the
>> patch and unpatched code?
On Tue, Sep 24, 2013 at 5:16 AM, Robert Haas wrote:
> On Fri, Sep 20, 2013 at 11:28 PM, David Rowley
> wrote:\
> > I put the above results into the attached spreadsheet. On my intel i5
> laptop
> > I'm seeing a slow down of about 1 second per million queries for the
> longer
> > log_line_prefix
On Fri, Sep 20, 2013 at 11:28 PM, David Rowley wrote:\
> I put the above results into the attached spreadsheet. On my intel i5 laptop
> I'm seeing a slow down of about 1 second per million queries for the longer
> log_line_prefix and about 1 second per 5 million queries with the shorter
> log_line
On Sat, Sep 21, 2013 at 7:18 AM, Robert Haas wrote:
> On Fri, Sep 20, 2013 at 3:15 AM, Albe Laurenz
> wrote:
> > David Rowley wrote:
> >> I moved the source around and I've patched against it again. New patch
> attached.
> >
> > Thank you, marked as ready for committer.
>
> /*
> + * helper func
On Fri, Sep 20, 2013 at 3:15 AM, Albe Laurenz wrote:
> David Rowley wrote:
>> I moved the source around and I've patched against it again. New patch
>> attached.
>
> Thank you, marked as ready for committer.
/*
+ * helper function for processing the format string in
+ * log_line_prefix()
+ * Th
David Rowley wrote:
> I moved the source around and I've patched against it again. New patch
> attached.
Thank you, marked as ready for committer.
Yours,
Laurenz Albe
--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:
http://www.postgres
On Fri, Sep 20, 2013 at 12:48 AM, Peter Eisentraut wrote:
> Something is weird in your latest patch. The header is:
>
> diff -u -r b/postgresql/doc/src/sgml/config.sgml
> a/postgresql/doc/src/sgml/config.sgml
> --- b/postgresql/doc/src/sgml/config.sgml 2013-09-09
> 23:40:52.356371191 +1200
Something is weird in your latest patch. The header is:
diff -u -r b/postgresql/doc/src/sgml/config.sgml
a/postgresql/doc/src/sgml/config.sgml
--- b/postgresql/doc/src/sgml/config.sgml 2013-09-09 23:40:52.356371191
+1200
+++ a/postgresql/doc/src/sgml/config.sgml 2013-09-19 22:13:26.
20 matches
Mail list logo
