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

On Wed, Nov 18, 2015 at 3:29 PM, Peter Geoghegan wrote: >> Overall this is very nice. Doing some real world index builds of >> short text (~20 bytes ascii) identifiers, I could easily get speed ups >> of 40% with your patch if I followed the philosophy of "give it as >> much

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

On Mon, Nov 23, 2015 at 6:27 AM, Jeff Janes wrote: > On Sun, Nov 22, 2015 at 8:16 AM, Masahiko Sawada > wrote: > >> Thank you for taking the time to review this patch! >> The updated version patch is attached. > > I am skeptical about just copying

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

On 20 November 2015 at 22:58, Peter Geoghegan wrote: > The numbers speak for themselves here. I just want to be clear about > the disadvantages of what I propose, even if it's well worth it > overall in most (all?) cases. > My feeling is that numbers rarely speak for

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

Stephen Frost wrote: > Even so, in the interest of having more fine-grained permission > controls, I've gone ahead and added a pg_switch_xlog default role. > Note that this means that pg_switch_xlog() can be called by both > pg_switch_xlog roles and pg_backup roles. I'd be very much against >

Re: [HACKERS] Re: In-core regression tests for replication, cascading, archiving, PITR, etc.

Michael Paquier wrote: > - Manage node information using package/class PostgresNode.pm and have > RecoveryTest use it. I have actually made PostgresNode bare-bone and simple > on purpose: one can initialize the node, append configuration parameters to > it and manage it through start/stop/restart

Re: [HACKERS] New email address

On 2015-11-24 13:43, Alvaro Herrera wrote: Larry Rosenman wrote: On 2015-11-24 13:11, Tom Lane wrote: >Kevin Grittner writes: >>On Tue, Nov 24, 2015 at 11:10 AM, Tom Lane wrote: change the From header (and add a Reply-To, so replies still work). >

Re: [HACKERS] New email address

Larry Rosenman writes: > On 2015-11-24 13:11, Tom Lane wrote: >> Kevin Grittner writes: >>> If this were done, would the other steps (not changing the subject >>> or body of the email) be necessary? >> >> See my followup: I think it's probably true that we

Re: [HACKERS] New email address

Larry Rosenman writes: > On 2015-11-24 13:43, Alvaro Herrera wrote: >> Of course, removing all the "List-" headers *and* our custom footers is >> a huge step backwards in terms of mailing list functionality :-( Also, >> removing the [HACKERS] etc tags will annoy some people, for

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

On Tuesday, November 24, 2015, Alvaro Herrera wrote: > Stephen Frost wrote: > > > Even so, in the interest of having more fine-grained permission > > controls, I've gone ahead and added a pg_switch_xlog default role. > > Note that this means that pg_switch_xlog() can be

Re: [HACKERS] New email address

On 11/24/2015 07:55 PM, Tom Lane wrote: > I wrote: >> "Rudolph T. Maceyko" writes: >>> The basic changes since Yahoo implemented their p=reject DMARC policy >>> last year (and others followed) were: >>> * make NO CHANGES to the body of the message--no headers, footers, etc. >>> *

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

Michael, * Michael Paquier (michael.paqu...@gmail.com) wrote: > On Sat, Nov 21, 2015 at 2:29 AM, Stephen Frost wrote: > > * Michael Paquier (michael.paqu...@gmail.com) wrote: > > Even so, in the interest of having more fine-grained permission > > controls, I've gone ahead and

Re: [HACKERS] New email address

Larry Rosenman wrote: > On 2015-11-24 13:11, Tom Lane wrote: > >Kevin Grittner writes: > >>On Tue, Nov 24, 2015 at 11:10 AM, Tom Lane wrote: > change the From header (and add a Reply-To, so replies still work). > > > >>If this were done, would the other

Re: [HACKERS] Revisiting pg_stat_statements and IN() (Was: Re: pg_stat_statements fingerprinting logic and ArrayExpr)

On Tue, Nov 24, 2015 at 10:55 PM, Jim Nasby wrote: > I'm not following your point. Obviously you can't compare int to text that > doesn't convert back to an int, but that's not what I was talking about. I didn't see what else you could have meant. In any case, the type

Re: [HACKERS] pg_hba_lookup function to get all matching pg_hba.conf entries

On Tue, Nov 17, 2015 at 9:37 AM, Peter Eisentraut wrote: > On 11/16/15 2:37 AM, Haribabu Kommi wrote: >> On Mon, Nov 16, 2015 at 2:30 PM, Peter Eisentraut wrote: >>> On 7/21/15 5:15 AM, Haribabu Kommi wrote: With the output of this view, administrator can

[HACKERS] What .gitignore files do in the tarball?

Collegues, I've noticed that source distribution archive of the postgresql contain more than hundred of .gitignore files and one .gitattributes. Is it just a bug nobody bothered to fix, or these files can make any sense outside git repository? Fix of the problem is quite trivial: diff --git

Re: [HACKERS] problem with msvc linker - cannot build orafce

Dne 24. 11. 2015 15:44 napsal uživatel "Chapman Flack" < c...@anastigmatix.net>: > > On 11/24/2015 05:33 AM, Kisung Kim wrote: > > 2015-11-24 8:12 GMT+09:00 Chapman Flack : > >> On 11/23/15 15:14, Tom Lane wrote: > >>> Lack of PGDLLIMPORT on the extern declaration, no doubt.

Re: [HACKERS] New email address

I wrote: > "Rudolph T. Maceyko" writes: >> The basic changes since Yahoo implemented their p=reject DMARC policy >> last year (and others followed) were: >> * make NO CHANGES to the body of the message--no headers, footers, etc. >> * make NO CHANGES to the subject header of the

Re: [HACKERS] WIP: About CMake v2

Hello hackers. News about CMake: I built postgres, initdb, createdb, psql, pg_ctl using CMake. After make install you can run initdb after run postgres after createdb and use it by psql. Only for Linux now and realy bugy (and the code is very dirt) but it work! If someone wants to test or to

Re: [HACKERS] parallelism and sorting

On Tue, Nov 24, 2015 at 7:53 PM, Robert Haas wrote: > > On Tue, Nov 24, 2015 at 7:59 AM, Amit Kapila wrote: > > On Tue, Nov 24, 2015 at 8:59 AM, Robert Haas wrote: > >> One idea about parallel sort is that perhaps if

Re: [HACKERS] New email address

Magnus Hagander writes: > On Tue, Nov 24, 2015 at 4:00 PM, Tom Lane wrote: >> If anyone thinks we might be motivated to become DMARC compliant, >> I can inquire for more details. But I won't bother unless there's >> real interest. > I'd definitely be

Re: [HACKERS] Bug in numeric multiplication

I wrote: > Note that div[qi+1], and indeed all the remaining dividend digits, are > large negative values. This is what you'd expect if the carry propagation > step hasn't run for awhile, which is a precondition for div[qi] being > large enough to cause an issue. When we compute 218943 * 1,

Re: [HACKERS] New email address

On Tue, Nov 24, 2015 at 11:10 AM, Tom Lane wrote: > Forwarded with Rudy's permission ... > From:"Rudolph T. Maceyko" > * when mail comes to the list from a domain that uses a p=reject DMARC > policy, CHANGE THE FROM HEADER so that it comes from the list.

Re: [HACKERS] New email address

Kevin Grittner writes: > On Tue, Nov 24, 2015 at 11:10 AM, Tom Lane wrote: >>> change the From header (and add a Reply-To, so replies still work). > If this were done, would the other steps (not changing the subject > or body of the email) be necessary?

Re: [HACKERS] New email address

On 2015-11-24 13:11, Tom Lane wrote: Kevin Grittner writes: On Tue, Nov 24, 2015 at 11:10 AM, Tom Lane wrote: change the From header (and add a Reply-To, so replies still work). If this were done, would the other steps (not changing the subject or

Re: [HACKERS] Revisiting pg_stat_statements and IN() (Was: Re: pg_stat_statements fingerprinting logic and ArrayExpr)

Peter Geoghegan writes: > On Tue, Dec 10, 2013 at 1:30 AM, Peter Geoghegan wrote: >> pg_stat_statements' fingerprinting logic considers the following two >> statements as distinct: >> >> select 1 in (1, 2, 3); >> select 1 in (1, 2, 3, 4); >> >> This is because

Re: [HACKERS] New email address

On 11/24/2015 07:55 PM, Tom Lane wrote: [snip] The clearly critical thing, though, is that when forwarding a message from a person at a DMARC-using domain, we would have to replace the From: line with something @postgresql.org. This is what gets it out from under the original domain's DMARC

Re: [HACKERS] Re: In-core regression tests for replication, cascading, archiving, PITR, etc.

On Wed, Nov 25, 2015 at 6:22 AM, Alvaro Herrera wrote: > Michael Paquier wrote: > > > - Manage node information using package/class PostgresNode.pm and have > > RecoveryTest use it. I have actually made PostgresNode bare-bone and > simple > > on purpose: one can

Re: [HACKERS] [PROPOSAL] VACUUM Progress Checker.

On 11/24/15 2:02 AM, Amit Langote wrote: It just occurred to me that we could do the instrumentation in >lazy_tid_reaped(). It might seem bad to do in increment for every tuple in >an index, but we're already doing a bsearch over the dead tuple list. >Presumably that's going to be a lot more

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

On Tue, Nov 24, 2015 at 3:32 PM, Simon Riggs wrote: > My feeling is that numbers rarely speak for themselves, without LSD. (Which > numbers?) Guffaw. > How are we doing here? Keen to see this work get committed, so we can move > onto parallel sort. What's the summary? I

Re: [HACKERS] parallelism and sorting

On 11/23/15 5:47 PM, Robert Haas wrote: 2. In Parallel Seq Scan, the determination of what page to scan next isn't dependent on the contents of any page previously scanned. In Parallel Index Scan, it is. Therefore, the amount of effective parallelism is likely to be less. This doesn't mean

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

On 25 November 2015 at 00:33, Peter Geoghegan wrote: > Parallel sort is very important. Robert, Amit and I had a call about > this earlier today. We're all in agreement that this should be > extended in that direction, and have a rough idea about how it ought > to fit together

Re: [HACKERS] [PROPOSAL] VACUUM Progress Checker.

On 2015/11/25 9:32, Jim Nasby wrote: > On 11/24/15 2:02 AM, Amit Langote wrote: >> Just to clarify, does this mean we report index vacuum progress in terms >> of index items processed (not pages)? If so, how do we get total number of >> index items to process (presumably across all indexes) for a

Re: [HACKERS] parallelism and sorting

On 11/24/15 7:10 AM, Ants Aasma wrote: The use case I have in mind is a table containing multiple years worth of (approximately) time series data, where overwhelming majority of queries are explicitly interested in recent data. Having a partial index with WHERE tstamp > $some_recent_tstamp

Re: [HACKERS] Revisiting pg_stat_statements and IN() (Was: Re: pg_stat_statements fingerprinting logic and ArrayExpr)

On 11/24/15 1:29 PM, Tom Lane wrote: So I suspect the real problem here is that we might want all of these things to look identical to pg_stat_statements: ARRAY[$1, $2, 42] ARRAY[$1, $2, $3, 47] '{1,2,3,47}'::int[] Don't see a very clean way to do that ... Another

Re: [HACKERS] WIP: About CMake v2

On Wed, Nov 25, 2015 at 1:35 AM, YUriy Zhuravlev wrote: > News about CMake: > I built postgres, initdb, createdb, psql, pg_ctl using CMake. > After make install you can run initdb after run postgres after createdb and > use it by psql. Only for Linux now and realy

Re: [HACKERS] Revisiting pg_stat_statements and IN() (Was: Re: pg_stat_statements fingerprinting logic and ArrayExpr)

On Tue, Nov 24, 2015 at 5:39 PM, Jim Nasby wrote: > Another not-uncommon case is IN ( '1', '2', ... , '2342' ); in other words, > treating an integer as text. A lot of frameworks like to do that and just > push the problem onto the database. I'm not sure what

Re: [HACKERS] [PROPOSAL] VACUUM Progress Checker.

On 11/24/15 7:02 PM, Amit Langote wrote: You'd get it from pg_class.reltuples for each index. Since all index >vacuuming is done strictly on a per-index-tuple basis, that's probably the >most accurate way to do it anyway. Important to remember though that the reltuples would be latest as of the

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

On Tue, Nov 24, 2015 at 4:46 PM, Simon Riggs wrote: >> I had a debug GUC (like the existing one to disable top-N heapsorts) >> that disabled "quicksort with spillover". That's almost the opposite >> of what you're asking for, though, because that makes us never use a >>

Re: [HACKERS] Re: In-core regression tests for replication, cascading, archiving, PITR, etc.

Michael Paquier wrote: > On Wed, Nov 25, 2015 at 6:22 AM, Alvaro Herrera > wrote: > > > Michael Paquier wrote: > > This looks great as a starting point. I think we should make TestLib > > depend on PostgresNode instead of the other way around. I will have a > > look

Re: [HACKERS] Re: In-core regression tests for replication, cascading, archiving, PITR, etc.

On Wed, Nov 25, 2015 at 10:55 AM, Alvaro Herrera wrote: > Michael Paquier wrote: > > On Wed, Nov 25, 2015 at 6:22 AM, Alvaro Herrera < > alvhe...@2ndquadrant.com> > > wrote: > > > > > Michael Paquier wrote: > > > > This looks great as a starting point. I think we

Re: [HACKERS] New email address

Greg Stark writes: > It'll still mess up everyone's contact book which will fill up with > these fake email addresses. And the Reply-To will mean private > responses will go to the list. Yeah, it's not pretty. But I'm not sure we're gonna have much choice if Gmail changes their

Re: [HACKERS] parallelism and sorting

On Tue, Nov 24, 2015 at 7:44 PM, Jim Nasby wrote: > On 11/23/15 5:47 PM, Robert Haas wrote: >> 2. In Parallel Seq Scan, the determination of what page to scan next >> isn't dependent on the contents of any page previously scanned. In >> Parallel Index Scan, it is.

Re: [HACKERS] Minor comment edits in nodeGather.c

On Tue, Nov 24, 2015 at 1:06 AM, Amit Langote wrote: > While going through nodeGather.c, I noticed portions of the file header > comment that may have been obsoleted by recent revisions of the relevant > parellelism code. For example, there is a reference to

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

On Tue, Nov 24, 2015 at 6:31 PM, Peter Geoghegan wrote: > (Note that the time taken to copy tuples comprising the final run is > not displayed or accounted for) I mean, comprising the second last run, the run shown, run 40. -- Peter Geoghegan -- Sent via pgsql-hackers

Re: [HACKERS] pg_receivexlog: spurious error message connecting to 9.3

On Tue, Nov 24, 2015 at 8:32 AM, Fujii Masao wrote: > On Tue, Nov 24, 2015 at 7:00 PM, Marco Nenciarini > wrote: >> Hi Robert, >> >> On 17/11/15 20:10, Robert Haas wrote: >>> On Tue, Nov 10, 2015 at 1:35 AM, Craig Ringer

Re: [HACKERS] Minor comment edits in nodeGather.c

On Tue, Nov 24, 2015 at 9:31 PM, Robert Haas wrote: > On Tue, Nov 24, 2015 at 1:06 AM, Amit Langote > wrote: >> While going through nodeGather.c, I noticed portions of the file header >> comment that may have been obsoleted by recent

Re: [HACKERS] Revisiting pg_stat_statements and IN() (Was: Re: pg_stat_statements fingerprinting logic and ArrayExpr)

I wrote: > Peter Geoghegan writes: >> This is because the ArrayExpr jumble case jumbles any ArrayExpr's list >> of elements recursively. In this case it's a list of Const nodes, and >> the fingerprinting logic jumbles those nodes indifferently. > I think this is a vastly

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

On Tue, Nov 24, 2015 at 5:42 PM, Greg Stark wrote: > Actually I kind of agree. What I would like to see is a series of > numbers for increasing sizes of sorts plotted against the same series > for the existing algorithm. Specifically with the sort size varying to > significantly

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

On Wed, Nov 25, 2015 at 12:33 AM, Peter Geoghegan wrote: > On Tue, Nov 24, 2015 at 3:32 PM, Simon Riggs wrote: >> My feeling is that numbers rarely speak for themselves, without LSD. (Which >> numbers?) > > Guffaw. Actually I kind of agree. What I would

Re: [HACKERS] New email address

On Tue, Nov 24, 2015 at 10:03 PM, José Luis Tallón wrote: >> From: Persons Real Name >> Reply-To: ... >> so that at least the person's name would still be readable in MUA >> displays. > > Yup It'll still mess up everyone's

Re: [HACKERS] Minor comment edits in nodeGather.c

On 2015/11/25 11:31, Robert Haas wrote: > On Tue, Nov 24, 2015 at 1:06 AM, Amit Langote > wrote: >> While going through nodeGather.c, I noticed portions of the file header >> comment that may have been obsoleted by recent revisions of the relevant >> parellelism

Re: [HACKERS] problem with msvc linker - cannot build orafce

On 24 November 2015 at 07:12, Chapman Flack wrote: > > What I (think I) took away from it was: > > 1. Un-PGDLLIMPORTed references to global *functions* work ok. > Maybe they are thunked and a little less efficient, but they work. > > 2. Un-PGDLLIMPORTed references to

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

Hi 2015-11-23 19:47 GMT+01:00 Alvaro Herrera : > Pavel Stehule wrote: > > > so pg_size_bytes is good enough for everybody? > > That seems good enough to me. > > I would have it accept GiB and GB and have both transform to base 2, and > have an optional boolean flag

Re: [HACKERS] problem with msvc linker - cannot build orafce

> > > I don't think that's necessary, per above. You just have to access the > vars via pointer indirection always, so long as *any* Pg version you > support has ever lacked dllexport or DEF entry, so you can't dllimport the > var. > > You could enable direct dllimport if PG_VERSION_NUM shows

Re: [HACKERS] WIP: About CMake v2

On 29 August 2015 at 02:04, Tom Lane wrote: > Christopher Browne writes: > > (Does CMake run on a VAX 11/780?? :-)) > > Yeah. I see the two major risks as being: > > 1. We limit ourselves to platforms that cmake works on. > > 2. We lose the ability to

Re: [HACKERS] problem with msvc linker - cannot build orafce

Craig Ringer writes: > Actually, if __declspec(dllexport) or a .DEF entry was added in, say, > 9.4.5, you could probably just: > #if PG_VERSION_NUM < 90405 > extern int* log_min_messages_p; > #define log_min_messages (*log_min_messages_p) > #endif > after including all

Re: [HACKERS] problem with msvc linker - cannot build orafce

On 25 November 2015 at 13:36, Tom Lane wrote: > Craig Ringer writes: > > Actually, if __declspec(dllexport) or a .DEF entry was added in, say, > > 9.4.5, you could probably just: > > > #if PG_VERSION_NUM < 90405 > > extern int* log_min_messages_p; > >

Re: [HACKERS] [DESIGN] ParallelAppend

On Mon, Nov 23, 2015 at 10:39 PM, Robert Haas wrote: > > On Mon, Nov 23, 2015 at 7:45 AM, Amit Kapila wrote: > > Without this patch, that 0.5 (or 50% of leaders effort) is considered for > > Gather node irrespective of the number of workers or

Re: [HACKERS] Revisiting pg_stat_statements and IN() (Was: Re: pg_stat_statements fingerprinting logic and ArrayExpr)

On 11/24/15 7:46 PM, Peter Geoghegan wrote: On Tue, Nov 24, 2015 at 5:39 PM, Jim Nasby wrote: Another not-uncommon case is IN ( '1', '2', ... , '2342' ); in other words, treating an integer as text. A lot of frameworks like to do that and just push the problem onto

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

On 11/24/15 10:57 PM, Pavel Stehule wrote: +errmsg("parameter \"%s\" isn't valid size value", Should read " isn't a valid size value" -- Jim Nasby, Data Architect, Blue Treble Consulting, Austin TX Experts in Analytics, Data Architecture and PostgreSQL Data in Trouble?

Re: [HACKERS] [PROPOSAL] VACUUM Progress Checker.

On 2015/11/21 14:38, Jim Nasby wrote: > On 11/19/15 7:29 PM, Amit Langote wrote: >>> Another option is to provide the means for the index scan routines to >>> >report their progress. Maybe every index AM won't use it, but it'd >>> >certainly be a lot better than staring at a long_running boolean.

Re: [HACKERS] [PROPOSAL] VACUUM Progress Checker.

On 2015/11/21 5:46, Robert Haas wrote: > On Thu, Nov 19, 2015 at 2:18 AM, Amit Langote > wrote: >> As someone pointed out upthread, the final heap truncate phase can take >> arbitrarily long and is outside the scope of lazy_scan_heap() to >> instrument. Perhaps a

Re: [HACKERS] pg_receivexlog: spurious error message connecting to 9.3

Hi Robert, On 17/11/15 20:10, Robert Haas wrote: > On Tue, Nov 10, 2015 at 1:35 AM, Craig Ringer wrote: >> On 10 November 2015 at 01:47, Marco Nenciarini >> wrote: >> >>> I've attached a little patch that removes the errors when connected

Re: [HACKERS] problem with msvc linker - cannot build orafce

2015-11-24 8:12 GMT+09:00 Chapman Flack : > On 11/23/15 15:14, Tom Lane wrote: > > Lack of PGDLLIMPORT on the extern declaration, no doubt. > > > > The fact that we've not heard this before implies that either nobody has > > ever tried to use orafce on Windows, or it only

Re: [HACKERS] parallelism and sorting

On Tue, Nov 24, 2015 at 7:59 AM, Amit Kapila wrote: > On Tue, Nov 24, 2015 at 8:59 AM, Robert Haas wrote: >> One idea about parallel sort is that perhaps if multiple workers feed >> data into the sort, they can each just sort what they have and

Re: [HACKERS] GIN pending list clean up exposure to SQL

On Sun, Nov 22, 2015 at 1:15 PM, Jaime Casanova wrote: > On 21 November 2015 at 03:54, Jim Nasby wrote: >> On 11/19/15 10:47 AM, Jaime Casanova wrote: >>> >>> - only superusers? >> >> >> I would think the owner of the table (index?)

Re: [HACKERS] Re: In-core regression tests for replication, cascading, archiving, PITR, etc.

On Tue, Nov 24, 2015 at 2:14 PM, Michael Paquier wrote: > I'll rework this patch and will update a new version soon. > So, attached is a new patch addressing all the comments received. The new version has the following changes: - Print more verbosely stderr output in

Re: [HACKERS] problem with msvc linker - cannot build orafce

On 11/24/2015 05:33 AM, Kisung Kim wrote: > 2015-11-24 8:12 GMT+09:00 Chapman Flack : >> On 11/23/15 15:14, Tom Lane wrote: >>> Lack of PGDLLIMPORT on the extern declaration, no doubt. >> > Actually, we encountered the situation before couple of months. > A client wanted to

Re: [HACKERS] New email address

Alvaro Herrera writes: > Magnus Hagander wrote: >> That's a direct effect of the dmarc policy change. Yahoo no longer supports >> their customers using mailing lists. They changed their policies for such >> emails to hard reject, which makes Gmail (and presumably others)

Re: [HACKERS] New email address

On Tue, Nov 24, 2015 at 4:00 PM, Tom Lane wrote: > Alvaro Herrera writes: > > Magnus Hagander wrote: > >> That's a direct effect of the dmarc policy change. Yahoo no longer > supports > >> their customers using mailing lists. They changed their

Re: [HACKERS] New email address

Magnus Hagander writes: > On Tue, Nov 24, 2015 at 4:00 PM, Tom Lane wrote: >> If anyone thinks we might be motivated to become DMARC compliant, >> I can inquire for more details. But I won't bother unless there's >> real interest. > I'd definitely be

Re: [HACKERS] New email address

Magnus Hagander wrote: > That's a direct effect of the dmarc policy change. Yahoo no longer supports > their customers using mailing lists. They changed their policies for such > emails to hard reject, which makes Gmail (and presumably others) stick them > in spam.. It would happen to all the

[HACKERS] Re: Revisiting pg_stat_statements and IN() (Was: Re: pg_stat_statements fingerprinting logic and ArrayExpr)

On Tue, Nov 24, 2015 at 7:53 AM, Peter Geoghegan wrote: > * How do other people feel about this? Personally, I've seen enough > problems of this kind in the field that "slippery slope" arguments > against this don't seem very compelling. I also always felt there should be some

Re: [HACKERS] New email address

On Tue, Nov 24, 2015 at 12:58 PM, Alvaro Herrera wrote: > Magnus Hagander wrote: > > > That's a direct effect of the dmarc policy change. Yahoo no longer > supports > > their customers using mailing lists. They changed their policies for such > > emails to hard reject,

Re: [HACKERS] Re: Revisiting pg_stat_statements and IN() (Was: Re: pg_stat_statements fingerprinting logic and ArrayExpr)

On Tue, Nov 24, 2015 at 2:25 PM, Greg Stark wrote: > On Tue, Nov 24, 2015 at 7:53 AM, Peter Geoghegan wrote: >> * How do other people feel about this? Personally, I've seen enough >> problems of this kind in the field that "slippery slope" arguments >> against

Re: [HACKERS] parallelism and sorting

On Tue, Nov 24, 2015 at 8:59 AM, Robert Haas wrote: > > > One idea about parallel sort is that perhaps if multiple workers feed > data into the sort, they can each just sort what they have and then > merge the results. Sounds like a good approach for parallel sorting,

Re: [HACKERS] pg_receivexlog: spurious error message connecting to 9.3

On Tue, Nov 24, 2015 at 7:00 PM, Marco Nenciarini wrote: > Hi Robert, > > On 17/11/15 20:10, Robert Haas wrote: >> On Tue, Nov 10, 2015 at 1:35 AM, Craig Ringer wrote: >>> On 10 November 2015 at 01:47, Marco Nenciarini >>>

Re: [HACKERS] parallelism and sorting

On Tue, Nov 24, 2015 at 5:29 AM, Robert Haas wrote: > On Mon, Nov 23, 2015 at 8:45 PM, Peter Geoghegan wrote: >> Beyond that, CREATE INDEX and CLUSTER utility >> cases will also need to be parallelized without all this executor >> infrastructure. > > Or,