Re: [HACKERS] pg_stat_statements and non default search_path

2016-10-15 Thread Julien Rouhaud
On 16/10/2016 02:38, Jim Nasby wrote: > On 10/10/16 12:58 AM, Julien Rouhaud wrote: >> Unless you mean deparsing the Query instead of using raw source text? I >> think that would solve this issue (and also the other issue when >> multiple queries are submitted at once, you get the normalized versi

Re: [HACKERS] process type escape for log_line_prefix

2016-10-15 Thread Jeff Janes
On Fri, Oct 14, 2016 at 11:51 AM, Andres Freund wrote: > On 2016-10-14 13:11:51 +0200, Christoph Berg wrote: > > Re: Michael Paquier 2016-02-10 5y9bpxz+dejbfcctebf06ef2u...@mail.gmail.com> > > > On Mon, Feb 8, 2016 at 11:32 PM, Andres Freund > wrote: > > > > Frequently when reading postgres log

Re: [HACKERS] pg_stat_statements and non default search_path

2016-10-15 Thread Jim Nasby
On 10/10/16 12:58 AM, Julien Rouhaud wrote: > Would another option be to temporarily set search_path to '' when > getting the query text? ISTM that would be the best option. I don't think that possible. The query text used is raw query text provided by the post_parse_analyse hook (ParseState->p

Re: [HACKERS] Fast AT ADD COLUMN with DEFAULTs

2016-10-15 Thread Serge Rielau
This feature was added in DB2 year ago. AFAIK it was not very successful. Regular compression techniques proved serve a broader and purpose and save more space. http://www.ibm.com/support/knowledgecenter/SSEPGG_9.7.0/com.ibm.db2.luw.admin.dbobj.doc/doc/c0056482.html [http://www.ibm.com/support/k

Re: [HACKERS] Fast AT ADD COLUMN with DEFAULTs

2016-10-15 Thread Jim Nasby
On 10/9/16 11:02 PM, Corey Huinker wrote: There's actually another use case here that's potentially extremely valuable for warehousing and other "big data": compact representation of a default value. I too would benefit from tables having either a default value in the event of a NO

Re: [HACKERS] Password identifiers, protocol aging and SCRAM protocol

2016-10-15 Thread Michael Paquier
On Fri, Oct 14, 2016 at 9:08 PM, Heikki Linnakangas wrote: > On 10/12/2016 11:11 AM, Michael Paquier wrote: > * Changed pg_strong_random() to return false on error, and let the callers > handle errors. That's more error-prone than throwing an error in the > function itself, as it's an easy mistake

Re: [HACKERS] Speed up Clog Access by increasing CLOG buffers

2016-10-15 Thread Amit Kapila
On Thu, Oct 13, 2016 at 7:53 AM, Tomas Vondra wrote: > On 10/12/2016 08:55 PM, Robert Haas wrote: >> On Wed, Oct 12, 2016 at 3:21 AM, Dilip Kumar wrote: >>> I think at higher client count from client count 96 onwards contention >>> on CLogControlLock is clearly visible and which is completely sol