On 04/10/14 11:21, Andres Freund wrote:
On 2014-10-03 18:16:28 -0400, Bruce Momjian wrote:
On Sat, Oct 4, 2014 at 12:13:00AM +0200, Andres Freund wrote:
Do we really want to expose a setting a few of us _might_ ask customers
to change?
They also will try that themselves. Our customers
On Sat, Oct 4, 2014 at 12:00:36PM +1300, Mark Kirkwood wrote:
I don't think we can offer absolutely accurate tuning advice, but I'm
sure we can give some guidance. Let me try.
+1
I think it is ok to document our reason for providing the new GUC -
along with that fact that it is a new
As discussed recently, here is an undocumented patch for
json_strip_nulls and jsonb_strip_nulls.
cheers
andrew
diff --git a/src/backend/utils/adt/jsonfuncs.c b/src/backend/utils/adt/jsonfuncs.c
index 2d00dbe..e9636d8 100644
--- a/src/backend/utils/adt/jsonfuncs.c
+++
On 10/3/14, 10:11 AM, Andres Freund wrote:
So 25% performance on a relatively small machine improvements aren't
worth a GUC? That are likely to be larger on a bigger machine? I
utterly fail to see why that's a service to our users.
I didn't say that. I said I don't think they're worth a GUC
On Fri, Oct 3, 2014 at 07:39:25PM -0400, Greg Smith wrote:
I do not disagree with you fundamentally here: this *is* worth
refining further, for sure, and the gains might be even greater if
that keeps going. My guess is just that the Postgres community
would not get a net benefit chasing that
Bruce Momjian br...@momjian.us writes:
Agreeed. Also, reality check --- we can't change postgresql.conf easily
without an initdb, and I think our last 9.4 initdb is going to be
9.4beta3, which is going to be packaged on Monday.
Good point: independently of all else, it's a bit late to be
On 2014-10-03 19:54:36 -0400, Tom Lane wrote:
Bruce Momjian br...@momjian.us writes:
Agreeed. Also, reality check --- we can't change postgresql.conf easily
without an initdb, and I think our last 9.4 initdb is going to be
9.4beta3, which is going to be packaged on Monday.
Good point:
On Sat, Oct 4, 2014 at 01:57:01AM +0200, Andres Freund wrote:
On 2014-10-03 19:54:36 -0400, Tom Lane wrote:
Bruce Momjian br...@momjian.us writes:
Agreeed. Also, reality check --- we can't change postgresql.conf easily
without an initdb, and I think our last 9.4 initdb is going to be
On Sat, Oct 4, 2014 at 6:48 AM, Andres Freund and...@2ndquadrant.com
wrote:
On 2014-10-03 14:02:08 -0400, Robert Haas wrote:
On Fri, Oct 3, 2014 at 7:57 AM, Andres Freund and...@2ndquadrant.com
wrote:
I do wonder whether --create/--drop aren't somewhat wierd for
pg_receivexlog. It's not
On 10/03/2014 05:04 PM, Bruce Momjian wrote:
On Sat, Oct 4, 2014 at 01:57:01AM +0200, Andres Freund wrote:
On 2014-10-03 19:54:36 -0400, Tom Lane wrote:
Bruce Momjian br...@momjian.us writes:
Agreeed. Also, reality check --- we can't change postgresql.conf easily
without an initdb, and I
Andres Freund and...@2ndquadrant.com writes:
On 2014-10-03 19:54:36 -0400, Tom Lane wrote:
Good point: independently of all else, it's a bit late to be adding new
features to 9.4.
This is getting absurd. The feature was there three days ago.
Well, an undocumented feature isn't a feature.
On 10/3/14, 5:23 PM, Andres Freund wrote:
How are we ever going to be able to tune it further without feedback
from actual production usage?
With improved targeted synthetic test cases that isolate the bottleneck
to where it's really obvious, way more obvious than it will ever be in
On 04/10/14 12:10, Bruce Momjian wrote:
On Sat, Oct 4, 2014 at 12:00:36PM +1300, Mark Kirkwood wrote:
I don't think we can offer absolutely accurate tuning advice, but I'm
sure we can give some guidance. Let me try.
+1
I think it is ok to document our reason for providing the new GUC -
On Sat, Oct 4, 2014 at 9:24 AM, Michael Paquier michael.paqu...@gmail.com
wrote:
On Sat, Oct 4, 2014 at 6:48 AM, Andres Freund and...@2ndquadrant.com
wrote:
On 2014-10-03 14:02:08 -0400, Robert Haas wrote:
On Fri, Oct 3, 2014 at 7:57 AM, Andres Freund and...@2ndquadrant.com
wrote:
I
Hi
2014-10-04 1:23 GMT+02:00 Andrew Dunstan and...@dunslane.net:
As discussed recently, here is an undocumented patch for json_strip_nulls
and jsonb_strip_nulls.
It is looking well
Regards
Pavel
cheers
andrew
--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
On 03/10/2014 05:53, Kouhei Kaigai wrote:
Yep, that's my pain. Even though usual query does not take many buffers
pinned,
my use case needs to fetch megabytes scale data at once because of performance
reason; page-by-page synchronous scan makes GPU being idle.
Doesn't your GPU have an async
101 - 116 of 116 matches
Mail list logo
