Re: [HACKERS] A typo in syncrep.c

Thank you Robert and sorry for bothering you with a silly question! I understand what I did clearly thanks to your attentive indication. At Mon, 21 Dec 2015 07:50:40 -0500, Robert Haas wrote in > >> >> + * lead the client to believe that the transaction is aborted, which > >> No, that's correc

Re: [HACKERS] Experimental evaluation of PostgreSQL's query optimizer

On 12/22/2015 02:40 AM, Craig Ringer wrote: > On 21 December 2015 at 23:57, Viktor Leis > wrote: > > > > Please have a look at Figure 6 (page 6) in > http://www.vldb.org/pvldb/vol9/p204-leis.pdf Disabling nested loop > joins without index scan (going from (a)

Re: [HACKERS] pgbench - allow backslash-continuations in custom scripts

I'm terribly sorry to have overlooked Febien's comment. I'll rework on this considering Febien's previous comment and Michael's this comment in the next CF. At Tue, 22 Dec 2015 16:17:07 +0900, Michael Paquier wrote in > On Wed, Oct 14, 2015 at 5:49 PM, Fabien COELHO wrote: > > > > Hello, > >

Re: [HACKERS] plpgsql - DECLARE - cannot to use %TYPE or %ROWTYPE for composite types

Hi 2015-12-21 16:21 GMT+01:00 Artur Zakirov : > Hi. > I have tried to do some review of this patch. Below are my comments. > > Introduction: > > This patch fixes and adds the following functionality: > - %TYPE - now can be used for composite types. > - %ARRAYTYPE - new functionality, provides the

Re: [HACKERS] Experimental evaluation of PostgreSQL's query optimizer

2015-12-22 9:28 GMT+01:00 Viktor Leis : > On 12/22/2015 02:40 AM, Craig Ringer wrote: > > On 21 December 2015 at 23:57, Viktor Leis l...@in.tum.de>> wrote: > > > > > > > > Please have a look at Figure 6 (page 6) in > > http://www.vldb.org/pvldb/vol9/p204-leis.pdf Disabling nested loop > >

Re: [HACKERS] parallel joins, and better parallel explain

On Fri, Dec 18, 2015 at 8:47 PM Robert Wrote, >> Yes, you are right, that create_gather_path() sets parallel_safe to false >> unconditionally but whenever we are building a non partial path, that time >> we should carry forward the parallel_safe state to its parent, and it seems >> like that part

Re: [HACKERS] A Typo in regress/sql/privileges.sql

On Fri, Dec 18, 2015 at 12:52 PM, Robert Haas wrote: > Mind you, I don't think "inference specification" is very good > terminology, but what's there right now is just wrong. It doesn't appear in the documentation. The term "inference specification" only appears where it's necessary to precisely

Re: [HACKERS] Some bugs in psql_complete of psql

Hello, I returned to this since Thomas' psql-completion patch has been committed. This patch has been recreated on it. "IN TABLESPACE xxx OWNED BY" has been alredy fixed so I removed it. The attched files are the following, 1. 0001-Fix-tab-complete-of-CREATE-INDEX.patch Fixes completion for C

Re: [HACKERS] custom function for converting human readable sizes to bytes

Hi 2015-12-21 16:11 GMT+01:00 Robert Haas : > On Sun, Dec 20, 2015 at 4:54 AM, Pavel Stehule > wrote: > > new update: > > > > 1. unit searching is case insensitive > > > > 2. initial support for binary byte prefixes - KiB, MiB, .. (IEC > standard), > > change behave for SI units > > > > Second

Re: [HACKERS] pglogical_output - a general purpose logical decoding output plugin

On 22 December 2015 at 15:17, Michael Paquier wrote: > On Mon, Dec 7, 2015 at 12:10 PM, Craig Ringer > wrote: > > Removed, change pushed. > > > > Also pushed a change to expose the decoded row data to row filter hooks. > > > > I won't cut a v4 for this, as I'm working on merging the SGML-ified d

Re: [HACKERS] Some questions about the array.

On понедельник, 21 декабря 2015 г. 20:28:43 MSK, Tom Lane wrote: With is_slice false, the only valid case is lidx==NULL, uidx!=NULL, as before for non-slice notation. But now it becomes valid syntax: select ('{1,2,3,4}'::int[])[NULL:NULL]; I do not think it's logical. Especially if in [:] functi

Re: [HACKERS] Minor code improvements to create_foreignscan_plan/ExecInitForeignScan

On Wed, Sep 9, 2015 at 7:08 PM, Etsuro Fujita wrote: > On 2015/07/10 18:40, Etsuro Fujita wrote: >> To save cycles, I modified create_foreignscan_plan so that it detects >> whether any system columns are requested if scanning a base relation. >> Also, I revised other code there a little bit. > > A

Re: [HACKERS] Mention column name in error messages

On Sun, Oct 4, 2015 at 12:23 AM, Andres Freund wrote: > On 2015-09-15 12:00:25 +0200, Franck Verrot wrote: >> diff --git a/src/backend/parser/parse_target.c >> b/src/backend/parser/parse_target.c >> index 1b3fcd6..78f82cd 100644 >> --- a/src/backend/parser/parse_target.c >> +++ b/src/backend/pars

Re: [HACKERS] checkpointer continuous flushing

On Thu, Dec 17, 2015 at 4:27 AM, Fabien COELHO wrote: > > Hello Tomas, > >> I'm planning to do some thorough benchmarking of the patches proposed in >> this thread, on various types of hardware (10k SAS drives and SSDs). But is >> that actually needed? I see Andres did some testing, as he posted s

Re: [HACKERS] [patch] Proposal for \rotate in psql

On Sun, Dec 20, 2015 at 6:49 AM, Pavel Stehule wrote: > attached patch allows align to center. > > everywhere where left/right align was allowed, the center align is allowed Moved to next CF, there is a fresh and new patch. -- Michael -- Sent via pgsql-hackers mailing list (pgsql-hackers@post

Re: [HACKERS] On columnar storage (2)

On Wed, Dec 9, 2015 at 3:10 PM, Jeff Janes wrote: > Could we get this rebased past the merge of the parallel execution commits? +1. Alvaro, Tomas, Simon, what are the next plans with those patches? -- Michael -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make change

Re: [HACKERS] [Proposal] Table partition + join pushdown

On Fri, Nov 20, 2015 at 9:05 PM, Taiki Kondo wrote: > I created v3 patch for this feature, and v1 patch for regression tests. > Please find attached. > > [blah review and replies] > > Please find from attached patch. This new patch did not actually get a review, moved to next CF. -- Michael --

Re: [HACKERS] Review: GiST support for UUIDs

On Tue, Sep 15, 2015 at 3:03 PM, Teodor Sigaev wrote: > > > Paul Jungwirth wrote: >>> >>> Or something like this in pseudocode: >>> >>> numeric = int8_numeric(*(uint64 *)(&i->data[0])) * >>> int8_numeric(MAX_INT64) + int8_numeric(*(uint64 *)(&i->data[8])) >> >> >> This is more like what I was hopi

Re: [HACKERS] Commit fest status for 2015-11

On Tue, Dec 22, 2015 at 4:04 PM, Michael Paquier wrote: > OK, if those don't get addressed soon, they will be moved to the next > CF with the same status. After a first pass, Numbers are getting down, I am just too tired to continue: Needs review: 13. Waiting on Author: 15. Ready for Committer:

[HACKERS] Maintenance on git.postgresql.org

I'm going to run some upgrade tasks on git.postgresql.org over the next hour or two. Thus it's likely to drop off the net a few times and come back, and things might work on and off. Anything pushed should be safe there normally, but it might be inaccessible for some periods of time, giving strang

Re: [HACKERS] On columnar storage (2)

Michael Paquier wrote: > On Wed, Dec 9, 2015 at 3:10 PM, Jeff Janes wrote: > > Could we get this rebased past the merge of the parallel execution commits? > > +1. Alvaro, Tomas, Simon, what are the next plans with those patches? Yeah, I've been working intermittently on getting the whole tree re

[HACKERS] Re: PATCH: Split stats file per database WAS: autovacuum stress-testing our system

On Mon, Feb 18, 2013 at 06:19:12PM -0300, Alvaro Herrera wrote: > I have pushed it now. Further testing, of course, is always welcome. While investigating stats.sql buildfarm failures, mostly on animals axolotl and shearwater, I found that this patch (commit 187492b) inadvertently removed the col

Re: [HACKERS] Remove Windows crash dump support?

On 22 December 2015 at 22:50, Craig Ringer wrote: > Hi all > > Back in 2010 I submitted a small feature to allow the creation of > minidumps when backends crashed; see > commit dcb09b595f88a3bca6097a6acc17bf2ec935d55f . > > At the time Windows lacked useful support for postmortem debugging and >

Re: [HACKERS] parallel joins, and better parallel explain

On Tue, Dec 22, 2015 at 4:14 AM, Dilip Kumar wrote: > On Fri, Dec 18, 2015 at 8:47 PM Robert Wrote, >>> Yes, you are right, that create_gather_path() sets parallel_safe to false >>> unconditionally but whenever we are building a non partial path, that >>> time >>> we should carry forward the paral

Re: [HACKERS] Some questions about the array.

Uriy Zhuravlev writes: > On понедельник, 21 декабря 2015 г. 20:28:43 MSK, Tom Lane > wrote: >> With is_slice false, the only valid >> case is lidx==NULL, uidx!=NULL, as before for non-slice notation. > But now it becomes valid syntax: > select ('{1,2,3,4}'::int[])[NULL:NULL];

Re: [HACKERS] Maintenance on git.postgresql.org

On Tue, Dec 22, 2015 at 2:56 PM, Magnus Hagander wrote: > I'm going to run some upgrade tasks on git.postgresql.org over the next > hour or two. Thus it's likely to drop off the net a few times and come > back, and things might work on and off. > > Anything pushed should be safe there normally, b

Re: [HACKERS] fix for readline terminal size problems when window is resized with open pager

On Wed, Dec 16, 2015 at 2:12 PM, Tom Lane wrote: > Merlin Moncure writes: >> On Wed, Dec 16, 2015 at 1:29 PM, Tom Lane wrote: >>> So I now think that print.c shouldn't be involved at all, and the right >>> thing to do is just have gets_interactive() invoke the resize function >>> immediately bef

Re: [HACKERS] Remove Windows crash dump support?

On Tue, Dec 22, 2015 at 3:53 PM, Craig Ringer wrote: > On 22 December 2015 at 22:50, Craig Ringer wrote: > >> Hi all >> >> Back in 2010 I submitted a small feature to allow the creation of >> minidumps when backends crashed; see >> commit dcb09b595f88a3bca6097a6acc17bf2ec935d55f . >> >> At the t

Re: [HACKERS] fix for readline terminal size problems when window is resized with open pager

Merlin Moncure writes: > This is working great. Is there anything left for me to do here? Nope, it's committed. regards, tom lane -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mail

[HACKERS] Remove Windows crash dump support?

Hi all Back in 2010 I submitted a small feature to allow the creation of minidumps when backends crashed; see commit dcb09b595f88a3bca6097a6acc17bf2ec935d55f . At the time Windows lacked useful support for postmortem debugging and crash-dump management in the operating system its self, especially

Re: [HACKERS] Patch to improve a few appendStringInfo* calls

On Mon, Dec 21, 2015 at 6:28 PM, David Rowley wrote: > According to grep -rE "appendStringInfoString\(.*\.data\);" . we have 13 > such matches. None of them seem to be in very performance critical places, > perhaps with the exception of xmlconcat(). > > Would you say that we should build a macro

Re: [HACKERS] Some questions about the array.

I think you are confused about the difference between a NULL constant (which would give rise to an A_Const syntax tree node) and a NULL syntax tree pointer (which cannot arise from any actual syntactical construct, and would only be present if the grammar put it there due to lack of any correspo

Re: [HACKERS] Patch: fix lock contention for HASHHDR.mutex

> > Actually, I'd like to improve all partitioned hashes instead of > > improve only one case. > > Yeah. I'm not sure that should be an LWLock rather than a spinlock, > but we can benchmark it both ways. I would like to share some preliminary results. I tested four implementations: - no loc

Re: [HACKERS] A typo in syncrep.c

On Tue, Dec 22, 2015 at 3:18 AM, Kyotaro HORIGUCHI wrote: > Thank you Robert and sorry for bothering you with a silly question! > > I understand what I did clearly thanks to your attentive indication. > > At Mon, 21 Dec 2015 07:50:40 -0500, Robert Haas wrote > in >> >> >> + * lead the client to

Re: [HACKERS] Remove Windows crash dump support?

Magnus Hagander writes: > On Tue, Dec 22, 2015 at 3:53 PM, Craig Ringer wrote: >>> Back in 2010 I submitted a small feature to allow the creation of >>> minidumps when backends crashed; see >>> commit dcb09b595f88a3bca6097a6acc17bf2ec935d55f . >>> At the time Windows lacked useful support for pos

Re: [HACKERS] Remove Windows crash dump support?

On 22.12.2015 18:28, Magnus Hagander wrote: On Tue, Dec 22, 2015 at 3:53 PM, Craig Ringer > wrote: On 22 December 2015 at 22:50, Craig Ringer mailto:cr...@2ndquadrant.com>> wrote: Hi all Back in 2010 I submitted a small feature to allow the

Re: [HACKERS] Experimental evaluation of PostgreSQL's query optimizer

On Tue, Dec 22, 2015 at 3:28 AM, Viktor Leis wrote: > I get 128.894ms vs. 183.724ms, i.e., a 43% slowdown for the hash > join. However, let me stress that this is really the extreme case: > > - If the join has few matches (due to inserting a value different from > 1 into r2), hash and nested loop

Re: [HACKERS] Experimental evaluation of PostgreSQL's query optimizer

Robert Haas writes: > From my point of view, one interesting fact about database > optimization is that the numbers 0 and 1 are phenomenally important > special cases. Yeah. > It is often the case that a join will return at most 1 > row per outer row, or that an aggregate will generate exactly 1

Re: [HACKERS] Some questions about the array.

New patch version in attachment. Thanks. -- Yury Zhuravlev Postgres Professional: http://www.postgrespro.com The Russian Postgres Companydiff --git a/doc/src/sgml/array.sgml b/doc/src/sgml/array.sgml index 4385a09..305cabb 100644 --- a/doc/src/sgml/array.sgml +++ b/doc/src/sgml/array.sgml @@ -

Re: [HACKERS] Some questions about the array.

Yury Zhuravlev writes: > New patch version in attachment. It's still awfully short on comments, but I'll see what I can do with it. regards, tom lane -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://ww

[HACKERS] Possible marginally-incompatible change to array subscripting

I'm reviewing Yury Zhuravlev's patch to allow array slice boundaries to be omitted, for example "a[4:]" means "the slice extending from element 4 to the last element of a". It strikes me that there's an improvement we could easily make for the case where a mixture of slice and non-slice syntax app

Re: [HACKERS] Using quicksort for every external sort run

On Sun, Dec 6, 2015 at 7:25 PM, Peter Geoghegan wrote: > On Tue, Nov 24, 2015 at 4:33 PM, Peter Geoghegan wrote: >> So, the bottom line is: This patch seems very good, is unlikely to >> have any notable downside (no case has been shown to be regressed), >> but has yet to receive code review. I am

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

On Mon, Dec 21, 2015 at 1:27 AM, Amit Kapila wrote: > On Fri, Dec 18, 2015 at 9:58 PM, Robert Haas wrote: >> >> On Fri, Dec 18, 2015 at 1:16 AM, Amit Kapila >> wrote: >> >> >> Some random comments: >> >> >> >> - TransactionGroupUpdateXidStatus could do just as well without >> >> add_proc_to_grou

Re: [HACKERS] Re: Reusing abbreviated keys during second pass of ordered [set] aggregates

On Mon, Dec 21, 2015 at 2:55 PM, Peter Geoghegan wrote: > On Mon, Dec 21, 2015 at 10:53 AM, Robert Haas wrote: >> PFA my proposal for comment changes for 9.5 and master. This is based >> on your 0001, but I edited somewhat. Please let me know your >> thoughts. I am not willing to go further an

Re: [HACKERS] Possible marginally-incompatible change to array subscripting

On Tue, Dec 22, 2015 at 11:51 AM, Tom Lane wrote: > I'm reviewing Yury Zhuravlev's patch to allow array slice boundaries to be > omitted, for example "a[4:]" means "the slice extending from element 4 to > the last element of a". It strikes me that there's an improvement we > could easily make for

Re: [HACKERS] Foreign join pushdown vs EvalPlanQual

On Tue, Dec 22, 2015 at 2:00 AM, Michael Paquier wrote: > On Tue, Dec 22, 2015 at 3:52 PM, Amit Langote > wrote: >> On 2015/12/22 15:24, Michael Paquier wrote: >>> As this debate continues, I think that moving this patch to the next >>> CF would make the most sense then.. So done this way. >> >>

Re: [HACKERS] pglogical_output - a general purpose logical decoding output plugin

On Tue, Dec 22, 2015 at 4:55 AM, Craig Ringer wrote: > I'm a touch frustrated by that, as a large part of the point of submitting > the output plugin separately and in advance of the downstream was to get > attention for it separately, as its own entity. A lot of effort has been put > into making

Re: [HACKERS] Minor code improvements to create_foreignscan_plan/ExecInitForeignScan

On Tue, Dec 22, 2015 at 7:32 AM, Michael Paquier wrote: > On Wed, Sep 9, 2015 at 7:08 PM, Etsuro Fujita > wrote: >> On 2015/07/10 18:40, Etsuro Fujita wrote: >>> To save cycles, I modified create_foreignscan_plan so that it detects >>> whether any system columns are requested if scanning a base r

Re: [HACKERS] Let PostgreSQL's On Schedule checkpoint write buffer smooth spread cycle by tuning IsCheckpointOnSchedule?

On Mon, Dec 21, 2015 at 7:51 AM, Fabien COELHO wrote: > I think that the 1.5 value somewhere in the patch is much too high for the > purpose because it shifts the checkpoint load quite a lot (50% more load at > the end of the checkpoint) just for the purpose of avoiding a spike which > lasts a few

Re: [HACKERS] Possible marginally-incompatible change to array subscripting

This would make no difference of course for the common case where the array lower bound is 1, but it seems a lot less arbitrary when it isn't. So I think we should strongly consider changing it to mean that, even though it would be non-backwards-compatible in such cases. Comments? If you break

Re: [HACKERS] Possible marginally-incompatible change to array subscripting

Robert Haas writes: > On Tue, Dec 22, 2015 at 11:51 AM, Tom Lane wrote: >> ISTM that if we'd had Yury's code in there from the beginning, what we >> would define this as meaning is "a[3:4][:5]", ie the implied range runs >> from whatever the array lower bound is up to the specified subscript. >

Re: [HACKERS] Possible marginally-incompatible change to array subscripting

Yury Zhuravlev writes: > If you break backwards compatibility, it can be done arrays > similar to C/C++/Python/Ruby and other languages style? > I'm sorry to bring up this thread again... I am not sure just exactly how incompatible that would be, but surely it would break enormously more code th

Re: [HACKERS] Possible marginally-incompatible change to array subscripting

On Tue, Dec 22, 2015 at 12:55 PM, Tom Lane wrote: > Robert Haas writes: >> On Tue, Dec 22, 2015 at 11:51 AM, Tom Lane wrote: >>> ISTM that if we'd had Yury's code in there from the beginning, what we >>> would define this as meaning is "a[3:4][:5]", ie the implied range runs >>> from whatever th

Re: [HACKERS] A Typo in regress/sql/privileges.sql

On Tue, Dec 22, 2015 at 4:36 AM, Peter Geoghegan wrote: > On Fri, Dec 18, 2015 at 12:52 PM, Robert Haas wrote: >> Mind you, I don't think "inference specification" is very good >> terminology, but what's there right now is just wrong. > > It doesn't appear in the documentation. The term "inferenc

Re: [HACKERS] Patch: fix lock contention for HASHHDR.mutex

On Tue, Dec 22, 2015 at 10:39 AM, Aleksander Alekseev wrote: > Obviously after splitting a freelist into NUM_LOCK_PARTITIONS > partitions (and assuming that all necessary locking/unlocking is done > on calling side) tables can't have more than NUM_LOCK_PARTITIONS > partitions because it would caus

Re: [HACKERS] A Typo in regress/sql/privileges.sql

Robert Haas wrote: > On Tue, Dec 22, 2015 at 4:36 AM, Peter Geoghegan wrote: > > On Fri, Dec 18, 2015 at 12:52 PM, Robert Haas wrote: > >> Mind you, I don't think "inference specification" is very good > >> terminology, but what's there right now is just wrong. > > > > It doesn't appear in the do

Re: [HACKERS] Possible marginally-incompatible change to array subscripting

On 12/22/2015 10:01 AM, Robert Haas wrote: On Tue, Dec 22, 2015 at 12:55 PM, Tom Lane wrote: Robert Haas writes: On Tue, Dec 22, 2015 at 11:51 AM, Tom Lane wrote: ISTM that if we'd had Yury's code in there from the beginning, what we would define this as meaning is "a[3:4][:5]", ie the impl

Re: [HACKERS] Possible marginally-incompatible change to array subscripting

2015-12-22 18:34 GMT+01:00 Robert Haas : > On Tue, Dec 22, 2015 at 11:51 AM, Tom Lane wrote: > > I'm reviewing Yury Zhuravlev's patch to allow array slice boundaries to > be > > omitted, for example "a[4:]" means "the slice extending from element 4 to > > the last element of a". It strikes me th

Re: [HACKERS] Re: Reusing abbreviated keys during second pass of ordered [set] aggregates

On Tue, Dec 22, 2015 at 9:31 AM, Robert Haas wrote: >> It has some nice properties, because unsigned integers are so simple >> and flexible. For example, we can do it with int4 sometimes, and then >> compare two attributes at once on 64-bit platforms. Maybe the second >> attribute (the second set

Re: [HACKERS] Getting sorted data from foreign server for merge join

On Mon, Dec 21, 2015 at 6:34 AM, Ashutosh Bapat wrote: >> I went over this patch in some detail today and did a lot of cosmetic >> cleanup. The results are attached. I'm fairly happy with this >> version, but let me know what you think. Of course, feedback from >> others is more than welcome al

Re: [HACKERS] A Typo in regress/sql/privileges.sql

On Tue, Dec 22, 2015 at 1:39 PM, Alvaro Herrera wrote: > Robert Haas wrote: >> On Tue, Dec 22, 2015 at 4:36 AM, Peter Geoghegan wrote: >> > On Fri, Dec 18, 2015 at 12:52 PM, Robert Haas >> > wrote: >> >> Mind you, I don't think "inference specification" is very good >> >> terminology, but what'

Re: [HACKERS] A Typo in regress/sql/privileges.sql

On Tue, Dec 22, 2015 at 11:01 AM, Robert Haas wrote: >> TBH I'm kinda inclined to sort this out by removing all usage of the >> word "inference" everywhere --- error messages and code comments and >> documentation wording, and replace it with some other wording as >> appropriate for each context.

Re: [HACKERS] Using quicksort for every external sort run

On Tue, Dec 22, 2015 at 9:10 AM, Robert Haas wrote: > So I was looking at the 0001 patch Thanks. I'm going to produce a revision of 0002 shortly, so perhaps hold off on that one. The big change there will be to call grow_memtuples() to allow us to increase the number of slots without palloc() ove

Re: [HACKERS] Additional role attributes && superuser review

* Michael Paquier (michael.paqu...@gmail.com) wrote: > On Tue, Dec 22, 2015 at 2:54 PM, Amit Langote > wrote: > > On 2015/12/22 14:05, Michael Paquier wrote: > >> On Tue, Dec 22, 2015 at 1:41 AM, Stephen Frost wrote: > >>> Updated and rebased patch attached which takes the 'pg_switch_xlog' > >>>

Re: [HACKERS] On columnar storage (2)

On Tue, Dec 22, 2015 at 11:43 PM, Alvaro Herrera wrote: > Michael Paquier wrote: >> On Wed, Dec 9, 2015 at 3:10 PM, Jeff Janes wrote: >> > Could we get this rebased past the merge of the parallel execution commits? >> >> +1. Alvaro, Tomas, Simon, what are the next plans with those patches? > > Ye

Re: [HACKERS] Using quicksort for every external sort run

On Tue, Dec 22, 2015 at 4:37 PM, Peter Geoghegan wrote: >> This looks like voodoo to me. I assume you tested it and maybe it >> gives correct answers, but it's got to be some kind of world record >> for number of arbitrary constants per SLOC, and there's no real >> justification for any of it. T

Re: [HACKERS] A Typo in regress/sql/privileges.sql

On Tue, Dec 22, 2015 at 2:23 PM, Peter Geoghegan wrote: > On Tue, Dec 22, 2015 at 11:01 AM, Robert Haas wrote: >>> TBH I'm kinda inclined to sort this out by removing all usage of the >>> word "inference" everywhere --- error messages and code comments and >>> documentation wording, and replace i

Re: [HACKERS] Re: Reusing abbreviated keys during second pass of ordered [set] aggregates

On Tue, Dec 22, 2015 at 12:31 PM, Robert Haas wrote: > On Mon, Dec 21, 2015 at 2:55 PM, Peter Geoghegan wrote: >> On Mon, Dec 21, 2015 at 10:53 AM, Robert Haas wrote: >>> PFA my proposal for comment changes for 9.5 and master. This is based >>> on your 0001, but I edited somewhat. Please let m

Re: [HACKERS] A Typo in regress/sql/privileges.sql

On Tue, Dec 22, 2015 at 2:58 PM, Robert Haas wrote: > If it's an axiom that there is nothing wrong with the term inference, > then obviously we should not change anything. But that seems to me to > be putting the cart before the horse. OK, then. What's wrong with the term inference? -- Peter G

Re: [HACKERS] Re: Reusing abbreviated keys during second pass of ordered [set] aggregates

On Tue, Dec 22, 2015 at 2:59 PM, Robert Haas wrote: >> Right. I don't think that we should back-patch that stuff into 9.5. > > OK, so I've gone ahead and committed and back-patched that. Can you > please rebase and repost the remainder as a 9.6 proposal? OK. I don't know why you didn't acknowle

Re: [HACKERS] A Typo in regress/sql/privileges.sql

On Tue, Dec 22, 2015 at 6:10 PM, Peter Geoghegan wrote: > On Tue, Dec 22, 2015 at 2:58 PM, Robert Haas wrote: >> If it's an axiom that there is nothing wrong with the term inference, >> then obviously we should not change anything. But that seems to me to >> be putting the cart before the horse.

Re: [HACKERS] A Typo in regress/sql/privileges.sql

On Tue, Dec 22, 2015 at 3:38 PM, Robert Haas wrote: > In my opinion a term more closely coupled to the concrete syntax would > be easier to understand. I have no objection to referring to the > *process* of trying to deduce a suitable index from the ON CONFLICT > clause as "inference". But calli

Re: [HACKERS] [PROPOSAL] Backup and recovery of pg_statistic

On Fri, Nov 27, 2015 at 06:52:59PM +0300, Dmitry Ivanov wrote: > Proposed changes to pg_dump > === > > Now that the approach has been developed, it may be applied to improve the > 'pg_dump' utility. Some minor code changes would make the 'pg_dump' emit > specially-formed

Re: [HACKERS] Using quicksort for every external sort run

On Tue, Dec 22, 2015 at 2:57 PM, Robert Haas wrote: > On Tue, Dec 22, 2015 at 4:37 PM, Peter Geoghegan wrote: >> That's not fair. DEFAULT_EQ_SEL, DEFAULT_RANGE_INEQ_SEL, and >> DEFAULT_NUM_DISTINCT are each about as arbitrary. We have to do >> something, though. >> > Sure, there are arbitrary nu

Re: [HACKERS] Freeze avoidance of very large table.

On Thu, Dec 17, 2015 at 06:44:46AM +, Simon Riggs wrote: > >> Thank you for having a look. > > > > I would not bother mentioning this detail in the pg_upgrade manual page: > > > > +   Since the format of visibility map has been changed in version 9.6, > > +   pg_upgrade

Re: [HACKERS] Possible marginally-incompatible change to array subscripting

Pavel Stehule writes: > 2015-12-22 18:34 GMT+01:00 Robert Haas : >> On Tue, Dec 22, 2015 at 11:51 AM, Tom Lane wrote: >>> ISTM that if we'd had Yury's code in there from the beginning, what we >>> would define this as meaning is "a[3:4][:5]", ie the implied range runs >>> from whatever the array

Re: [HACKERS] Some questions about the array.

Yury Zhuravlev writes: > New patch version in attachment. I've committed this with a number of revisions, mostly but not entirely cosmetic. Worthy of note: * I did not like the way you were inserting the replacement subscript values: + arrays = (AnyArrayType *)DatumGet

[HACKERS] pgbench --latency-limit option

While playing with 9.5's pgbench, I faced with a strange behavior. $ pgbench -p 11002 --rate 2 --latency-limit 1 -c 10 -T 10 test starting vacuum...end. transaction type: TPC-B (sort of) scaling factor: 1 query mode: simple number of clients: 10 number of threads: 1 duration: 10 s number of transa

Re: [HACKERS] Support for N synchronous standby servers - take 2

On Fri, Dec 18, 2015 at 7:38 AM, Masahiko Sawada wrote: [000-_multi_sync_replication_v3.patch] Hi Masahiko, I haven't tested this version of the patch but I have some comments on the code. +/* Is this wal sender considerable one? */ +bool +SyncRepActiveListedWalSender(int num) Maybe "Is this w

Re: [HACKERS] Possible marginally-incompatible change to array subscripting

On 12/22/15 12:01 PM, Tom Lane wrote: Yury Zhuravlev writes: If you break backwards compatibility, it can be done arrays similar to C/C++/Python/Ruby and other languages style? I'm sorry to bring up this thread again... I am not sure just exactly how incompatible that would be, but surely it

Re: [HACKERS] Support for N synchronous standby servers - take 2

On Wed, Dec 23, 2015 at 3:50 PM, Thomas Munro wrote: > On Fri, Dec 18, 2015 at 7:38 AM, Masahiko Sawada > wrote: > [000-_multi_sync_replication_v3.patch] > > Hi Masahiko, > > I haven't tested this version of the patch but I have some comments on the > code. > > +/* Is this wal sender considerab

Re: [HACKERS] [PROPOSAL] Backup and recovery of pg_statistic

Bruce Momjian writes: > On Fri, Nov 27, 2015 at 06:52:59PM +0300, Dmitry Ivanov wrote: >> Now that the approach has been developed, it may be applied to improve the >> 'pg_dump' utility. Some minor code changes would make the 'pg_dump' emit >> specially-formed recovery INSERTS for 'pg_statistic'

Re: [HACKERS] Possible marginally-incompatible change to array subscripting

Jim Nasby writes: > One could theoretically construct a custom "type" that followed more > traditional semantics, but then you'd lose all the syntax... which I > suspect would make any such "type" all but unusable. The other problem > would be having it deal with any other data type, but at lea

Re: [HACKERS] Getting sorted data from foreign server for merge join

Thanks. On Wed, Dec 23, 2015 at 12:24 AM, Robert Haas wrote: > On Mon, Dec 21, 2015 at 6:34 AM, Ashutosh Bapat > wrote: > >> I went over this patch in some detail today and did a lot of cosmetic > >> cleanup. The results are attached. I'm fairly happy with this > >> version, but let me know w

Re: [HACKERS] Add scale(numeric)

Hi 2015-11-19 3:27 GMT+01:00 Marko Tiikkaja : > Hi, > > As suggested in 5643125e.1030...@joh.to, here's a patch for extracting > the scale out of a numeric. > > This is 2016-01 CF material, but if someone wants to bas^H^H^Hsay nice > things in the meanwhile, feel free. > This patch is pretty tri

Re: [HACKERS] Re: Reusing abbreviated keys during second pass of ordered [set] aggregates

On Tue, Dec 22, 2015 at 2:59 PM, Robert Haas wrote: > OK, so I've gone ahead and committed and back-patched that. Can you > please rebase and repost the remainder as a 9.6 proposal? I attach a rebased patch for 9.6 only. -- Peter Geoghegan From 4bc33a602822ef0d56222f03174d71bbb4cd126b Mon Sep

Re: [HACKERS] parallel joins, and better parallel explain

On Tue, Dec 22, 2015 at 8:30 PM, Robert Haas wrote: > On Tue, Dec 22, 2015 at 4:14 AM, Dilip Kumar > wrote: > > On Fri, Dec 18, 2015 at 8:47 PM Robert Wrote, > >>> Yes, you are right, that create_gather_path() sets parallel_safe to > false > >>> unconditionally but whenever we are building a non