Re: [HACKERS] Statement timeout

> Oops. Previous example was not appropriate. Here are revised > examples. (in any case, the time consumed at parse and bind are small, > and I omit the CHECK_FOR_INTERRUPTS after these commands) > > [example 1] > > statement_timeout = 3s > > parse(statement1) -- time 0. set statement timout tim

Re: [HACKERS] Parallel pg_dump's error reporting doesn't work worth squat

Hello, At Fri, 27 May 2016 13:20:20 -0400, Tom Lane wrote in <14603.1464369...@sss.pgh.pa.us> > Kyotaro HORIGUCHI writes: > > By the way, the reason of the "invalid snapshot identifier" is > > that some worker threads try to use it after the connection on > > the first worker closed. > > ... B

Re: [HACKERS] 9.4 -> 9.5 regression with queries through pgbouncer on RHEL 6

27 мая 2016 г., в 19:57, Vladimir Borodin написал(а):-performance+hackers25 мая 2016 г., в 17:33, Vladimir Borodin написал(а):Hi all.We have found that queries through PgBouncer 1.7.2 (with transaction pooling) to local PostgreSQL are almost two times slower in

[HACKERS] Binary I/O for isn extension

Hi. Attached is a small patch which adds binary input/output for the types added by the isn extension. Shay isn-binary.patch Description: Binary data -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/

Re: [HACKERS] Question and suggestion about application binary compatibility policy

On 31/05/2016 08:10, Tsunakawa, Takayuki wrote: From: Michael Meskes [mailto:mes...@postgresql.org] Yes, but Windows users probably don't understand or know it. So, I suggested explicitly describing the application binary compatibility policy in the PostgreSQL manual. What do you think about

Re: [HACKERS] IPv6 link-local addresses and init data type

On 05/31/2016 04:06 AM, Tom Lane wrote: Andreas Karlsson writes: On 05/31/2016 02:37 AM, Haribabu Kommi wrote: The % delimiter character is not only used at the end of the IPV6 address, from the RFC document, it is possible as follows also. fe80::%2/64 we need to handle both the scenarios,

Re: [HACKERS] Binary I/O for isn extension

Hi, Thanks for the patch, you can add it to our commitfest app so it gets reviewed in the next commitfest. https://commitfest.postgresql.org/ A suggestion to make it easier for your patch to be accepted: When adding new functions to an extension you need to bump the version of the extension

Re: [HACKERS] Binary I/O for isn extension

Hello, Attached is a small patch which adds binary input/output for the types added by the isn extension. I added this patch to the next CF (2016-09) under "Miscellaneous". Out of curiosity, what is the motivation? -- Fabien. -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresq

Re: [HACKERS] Binary I/O for isn extension

> > When adding new functions to an extension you need to bump the version of > the extension by renaming the file, updating the .control file, creating an > upgrade script, and updating the Makefile to include the new files. Thanks for the guidance, I'll fix all that and resubmit a patch.

Re: [HACKERS] Binary I/O for isn extension

Thanks for the patch, you can add it to our commitfest app so it gets reviewed in the next commitfest. I did this. A suggestion to make it easier for your patch to be accepted: When adding new functions to an extension you need to bump the version of the extension by renaming the file, upd

Re: [HACKERS] Binary I/O for isn extension

> > I added this patch to the next CF (2016-09) under "Miscellaneous". > Thanks! > Out of curiosity, what is the motivation? I'm the owner of Npgsql, the open-source .NET driver for PostgreSQL, which is a binary-first driver. That is, working with types that have no binary I/O is possible but

Re: [HACKERS] Question and suggestion about application binary compatibility policy

> I couldn't find appropriate system documentation.  Regarding Linux, I > remember I saw some HOWTO on tldp.org website which explains the > concept of shared library soname, but it's not very friendly for > users who just want to know the application binary compatibility > policy of PostgreSQL.  A

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

Hi, On 05/26/2016 10:10 PM, Tom Lane wrote: Tomas Vondra writes: Attached is a patch that should fix the coalescing, including the clock skew detection. In the end I reorganized the code a bit, moving the check at the end, after the clock skew detection. Otherwise I'd have to do the clock skew

[HACKERS] Logical replication & oldest XID.

Hi, We are using logical replication in multimaster and are faced with some interesting problem with "frozen" procArray->replication_slot_xmin. This variable is adjusted by ProcArraySetReplicationSlotXmin which is invoked by ReplicationSlotsComputeRequiredXmin, which is in turn is called by Log

Re: [HACKERS] Re: [COMMITTERS] pgsql: Avoid extra locks in GetSnapshotData if old_snapshot_threshold

On Fri, May 27, 2016 at 10:58 AM, Kevin Grittner wrote: >> As far as I can see normal index builds will allow concurrent hot >> prunes and everything; since those only require page-level >> exclusive locks. >> >> So for !concurrent builds we might end up with a corrupt index. > > ... by which you

Re: [HACKERS] Rename max_parallel_degree?

On Sun, May 29, 2016 at 1:33 AM, Noah Misch wrote: > On Fri, May 06, 2016 at 02:52:30PM -0400, Robert Haas wrote: >> OK, my reading of this thread is that there is a consensus is to >> redefine max_parallel_degree=1 as "no parallelism" and >> max_parallel_degree>1 as "parallelism using a leader pl

Re: [HACKERS] Statement timeout

Tatsuo Ishii writes: >> Oops. Previous example was not appropriate. Here are revised >> examples. (in any case, the time consumed at parse and bind are small, >> and I omit the CHECK_FOR_INTERRUPTS after these commands) FWIW, I think the existing behavior is just fine. It corresponds to what PQe

Re: [HACKERS] Re: [COMMITTERS] pgsql: Avoid extra locks in GetSnapshotData if old_snapshot_threshold

On Tue, May 31, 2016 at 10:03 AM, Robert Haas wrote: > On Fri, May 27, 2016 at 10:58 AM, Kevin Grittner wrote: >>> As far as I can see normal index builds will allow concurrent hot >>> prunes and everything; since those only require page-level >>> exclusive locks. >>> >>> So for !concurrent build

Re: [HACKERS] Suggestion for --truncate-tables to pg_restore

Hi there, Refering to https://www.postgresql.org/message-id/1352742344.21373.4@mofo I'm running into situations where I'd need to bulk transfer of data tables across servers, but a drop and recreate schema isn't feasible as we are running different permissions etc. on the two databases. Thus

Re: [HACKERS] Parallel pg_dump's error reporting doesn't work worth squat

Kyotaro HORIGUCHI writes: > At Fri, 27 May 2016 13:20:20 -0400, Tom Lane wrote in > <14603.1464369...@sss.pgh.pa.us> >> Kyotaro HORIGUCHI writes: >>> By the way, the reason of the "invalid snapshot identifier" is >>> that some worker threads try to use it after the connection on >>> the first w

Re: [HACKERS] [PATCH][Documination] Add optional USING keyword before opclass name in INSERT statemet

On Thu, May 26, 2016 at 3:28 PM, Tom Lane wrote: > Nikolay Shaplov writes: >> Actually I did not expected any discussion for this case. Documentations >> missed an optional keyword, documentation should be fixed. > > 99% of the time, you'd be right. But this is an unusual case, for the > reasons

Re: [HACKERS] [PATCH][Documination] Add optional USING keyword before opclass name in INSERT statemet

Robert Haas writes: > On Thu, May 26, 2016 at 3:28 PM, Tom Lane wrote: >> 99% of the time, you'd be right. But this is an unusual case, for the >> reasons I mentioned before. > I tend to agree with Nikolay. I can't see much upside in making this > change. At best, nothing will break. At wors

Re: [HACKERS] parallel.c is not marked as test covered

On 5/9/16 10:50 AM, Andres Freund wrote: I think it's a good idea to run a force-parallel run on some buildfarm members. But I'm rather convinced that the core tests run by all animals need some minimal coverage of parallel queries. Both because otherwise it'll be hard to get some coverage of unu

Re: [HACKERS] copyParamList

On Fri, May 27, 2016 at 6:07 PM, Andrew Gierth wrote: > copyParamList does not respect from->paramMask, in what looks to me like > an obvious oversight: > > retval->paramMask = NULL; > [...] > /* Ignore parameters we don't need, to save cycles and space. */ > if (retval->paramM

Re: [HACKERS] Rename max_parallel_degree?

On 05/31/2016 09:15 AM, Robert Haas wrote: > On Sun, May 29, 2016 at 1:33 AM, Noah Misch wrote: >> On Fri, May 06, 2016 at 02:52:30PM -0400, Robert Haas wrote: >>> OK, my reading of this thread is that there is a consensus is to >>> redefine max_parallel_degree=1 as "no parallelism" and >>> max_pa

Re: [HACKERS] Parallel safety tagging of extension functions

Andreas Karlsson writes: > So how to best change the function signatures? I do not think it is > possible without locking indexes by just using the SQL commands. You > cannot drop a function from the operator family without dropping the > operator class first. Ugh. I had been thinking that yo

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

Tomas Vondra writes: > On 05/26/2016 10:10 PM, Tom Lane wrote: >> I posted a patch at >> https://www.postgresql.org/message-id/13023.1464213...@sss.pgh.pa.us >> which I think is functionally equivalent to what you have here, but >> it goes to some lengths to make the code more readable, whereas th

Re: [HACKERS] Rename max_parallel_degree?

Josh berkus writes: > I realize there's a lot of water under the bridge here, but I think > we're going to get 1000 questions on -general of the type: "I asked for > 8 parallel workers, why did I only get 7?". I believe we will regret > this change. > So, one vote from me to revert. Well, that

Re: [HACKERS] Rename max_parallel_degree?

On 05/31/2016 10:03 AM, Tom Lane wrote: > Josh berkus writes: >> I realize there's a lot of water under the bridge here, but I think >> we're going to get 1000 questions on -general of the type: "I asked for >> 8 parallel workers, why did I only get 7?". I believe we will regret >> this change.

Re: [HACKERS] Rename max_parallel_degree?

On 05/31/2016 10:10 AM, Josh berkus wrote: Compare this: "max_parallel is the maximum number of parallel workers which will work on each stage of the query which is parallizable. If you set it to 4, you get up to 4 workers." with this: "max_parallel_degree is the amount of parallelism in the

Re: [HACKERS] Rename max_parallel_degree?

On Tue, May 31, 2016 at 10:10 AM, Josh berkus wrote: > "max_parallel_degree is the amount of parallelism in the query, with the > understanding that the original parent process counts as 1, which means > that if you set it to 1 you get no parallelism, and if you want 4 > parallel workers you need

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

On 05/31/2016 06:59 PM, Tom Lane wrote: Tomas Vondra writes: On 05/26/2016 10:10 PM, Tom Lane wrote: I posted a patch at https://www.postgresql.org/message-id/13023.1464213...@sss.pgh.pa.us which I think is functionally equivalent to what you have here, but it goes to some lengths to make the

Re: [HACKERS] Rename max_parallel_degree?

On 05/31/2016 10:16 AM, Peter Geoghegan wrote: > On Tue, May 31, 2016 at 10:10 AM, Josh berkus wrote: >> "max_parallel_degree is the amount of parallelism in the query, with the >> understanding that the original parent process counts as 1, which means >> that if you set it to 1 you get no paralle

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

Tomas Vondra writes: > On 05/31/2016 06:59 PM, Tom Lane wrote: >> I'm confused here --- are you speaking of having removed >> if (msg->cutoff_time > req->request_time) >> req->request_time = msg->cutoff_time; >> ? That is not a check for clock skew, it's intending to be sure that

Re: [HACKERS] Rename max_parallel_degree?

Josh berkus writes: > On 05/31/2016 10:16 AM, Peter Geoghegan wrote: >> But the distinction between parallel workers and backends that can >> participate in parallel query does need to be user-visible. Worker >> processes are a commodity (i.e. the user must consider >> max_worker_processes). > It

Re: [HACKERS] Rename max_parallel_degree?

On Tue, May 31, 2016 at 10:23 AM, Josh berkus wrote: > It's still WAY simpler to understand "max_parallel is the number of > parallel workers I requested". (Sorry Josh, somehow hit reply, not reply-all) Yes, it is. But as long as parallel workers are not really that distinct to the leader-as-wor

Re: [HACKERS] Rename max_parallel_degree?

On 05/31/2016 10:30 AM, Tom Lane wrote: Josh berkus writes: On 05/31/2016 10:16 AM, Peter Geoghegan wrote: But the distinction between parallel workers and backends that can participate in parallel query does need to be user-visible. Worker processes are a commodity (i.e. the user must conside

Re: [HACKERS] Rename max_parallel_degree?

On 05/31/2016 10:38 AM, Peter Geoghegan wrote: > On Tue, May 31, 2016 at 10:23 AM, Josh berkus wrote: >> It's still WAY simpler to understand "max_parallel is the number of >> parallel workers I requested". > > (Sorry Josh, somehow hit reply, not reply-all) > > Yes, it is. But as long as paralle

[HACKERS] Rename synchronous_standby_names?

Hi, Are we going to change synchronous_standby_names? Certainly the GUC is not *only* a list of names anymore. synchronous_standby_config? synchronous_standbys (adjust to correct english if necesary)? -- Jaime Casanova www.2ndQuadrant.com PostgreSQL Development, 24x7 Suppor

Re: [HACKERS] Rename max_parallel_degree?

On Tue, May 31, 2016 at 10:46 AM, Josh berkus wrote: > In parallel seq scan and join, do the "masters" behave as workers as well? It depends. They will if they can. If the parallel seq scan leader isn't getting enough work to do from workers (enough tuples to process from the shared memory queue)

Re: [HACKERS] Rename max_parallel_degree?

I wrote: > I really think that a GUC named "max_parallel_workers", which in fact > limits the number of workers and not something else, is the way to go. To be concrete, I suggest comparing the attached documentation patch with Robert's. Which one is more understandable? (I have not bothered pre

Re: [HACKERS] Rename max_parallel_degree?

On 05/31/2016 10:51 AM, Peter Geoghegan wrote: > On Tue, May 31, 2016 at 10:46 AM, Josh berkus wrote: >> In parallel seq scan and join, do the "masters" behave as workers as well? > > It depends. They will if they can. If the parallel seq scan leader > isn't getting enough work to do from workers

Re: [HACKERS] Rename synchronous_standby_names?

Jaime Casanova writes: > Are we going to change synchronous_standby_names? Certainly the GUC is > not *only* a list of names anymore. > synchronous_standby_config? > synchronous_standbys (adjust to correct english if necesary)? I could get behind renaming it to synchronous_standby_config ...

Re: [HACKERS] Logic behind parallel default? WAS: Rename max_parallel_degree?

On 05/31/2016 11:00 AM, Tom Lane wrote: > ! If this occurs, the plan will run with fewer workers than expected, > ! which may be inefficient. The default value is 2. Setting this > ! value to 0 disables parallel query execution. Is there a thread on how we determined t

Re: [HACKERS] Rename max_parallel_degree?

On Tuesday, May 31, 2016, Tom Lane wrote: > Josh berkus > writes: > > On 05/31/2016 10:16 AM, Peter Geoghegan wrote: > >> But the distinction between parallel workers and backends that can > >> participate in parallel query does need to be user-visible. Worker > >> processes are a commodity (i.e.

Re: [HACKERS] Rename max_parallel_degree?

Peter Geoghegan writes: > Even when the leader is consuming input from workers, that's still perhaps > pegging one CPU core. So, it doesn't really invalidate what I said about > the number of cores being the primary consideration. Agreed, but if we think that people need to be thinking in those t

Re: [HACKERS] Rename max_parallel_degree?

On Tue, May 31, 2016 at 11:02 AM, Josh berkus wrote: > I get where you're coming from, but I think Haas's query plan output is > going to show us the confusion we're going to get. So we need to either > change the parameter, the explain output, or brace ourselves for endless > repeated questions.

Re: [HACKERS] Logic behind parallel default? WAS: Rename max_parallel_degree?

Josh berkus writes: > Is there a thread on how we determined this default of 2? I can't find > one under likely search terms. The 9.6 open-items list cites https://www.postgresql.org/message-id/flat/20160420174631.3qjjhpwsvvx5b...@alap3.anarazel.de regards, tom lane -

Re: [HACKERS] Logic behind parallel default? WAS: Rename max_parallel_degree?

On 05/31/2016 11:05 AM, Josh berkus wrote: On 05/31/2016 11:00 AM, Tom Lane wrote: ! If this occurs, the plan will run with fewer workers than expected, ! which may be inefficient. The default value is 2. Setting this ! value to 0 disables parallel query execution.

Re: [HACKERS] Rename max_parallel_degree?

On Tue, May 31, 2016 at 11:09 AM, Peter Geoghegan wrote: > The only reason I favor defining parallel_degree = 1 I meant "redefining max_parallel_degree =1 to effectively disable parallel query", of course. -- Peter Geoghegan -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.o

Re: [HACKERS] Rename max_parallel_degree?

On Tuesday, May 31, 2016, Tom Lane wrote: > I wrote: > > I really think that a GUC named "max_parallel_workers", which in fact > > limits the number of workers and not something else, is the way to go. > > To be concrete, I suggest comparing the attached documentation patch > with Robert's. Whic

Re: [HACKERS] Rename max_parallel_degree?

On 5/31/16 2:02 PM, Josh berkus wrote: I get where you're coming from, but I think Haas's query plan output is going to show us the confusion we're going to get. So we need to either change the parameter, the explain output, or brace ourselves for endless repeated questions. Changing the expla

Re: [HACKERS] Rename max_parallel_degree?

On Tuesday, May 31, 2016, Peter Geoghegan wrote: > On Tue, May 31, 2016 at 11:02 AM, Josh berkus > wrote: > > I get where you're coming from, but I think Haas's query plan output is > > going to show us the confusion we're going to get. So we need to either > > change the parameter, the explain

Re: [HACKERS] Rename max_parallel_degree?

"David G. Johnston" writes: > On Tuesday, May 31, 2016, Tom Lane wrote: >>> I really think that a GUC named "max_parallel_workers", which in fact >>> limits the number of workers and not something else, is the way to go. > If going this route I'd still rather add the word "assisting" > or "addit

Re: [HACKERS] Rename max_parallel_degree?

On Tue, May 31, 2016 at 11:17 AM, Peter Eisentraut wrote: > Changing the explain output doesn't sound so bad to me. > > The users' problem is that the parameter setting ought to match the EXPLAIN > output. > > The developers' problem is that the EXPLAIN output actually corresponds to > leader + (N

Re: [HACKERS] Rename synchronous_standby_names?

On 5/31/16 1:47 PM, Jaime Casanova wrote: Are we going to change synchronous_standby_names? Certainly the GUC is not *only* a list of names anymore. synchronous_standby_config? synchronous_standbys (adjust to correct english if necesary)? If the existing values are still going to be accepted,

Re: [HACKERS] Rename max_parallel_degree?

"David G. Johnston" writes: > On Tuesday, May 31, 2016, Tom Lane wrote: >> I really think that a GUC named "max_parallel_workers", which in fact >> limits the number of workers and not something else, is the way to go. > What is your opinion on the internal name for this? Leave it as "degree"?

Re: [HACKERS] Rename max_parallel_degree?

On 05/31/2016 11:17 AM, Peter Eisentraut wrote: > On 5/31/16 2:02 PM, Josh berkus wrote: >> I get where you're coming from, but I think Haas's query plan output is >> going to show us the confusion we're going to get. So we need to either >> change the parameter, the explain output, or brace ourse

Re: [HACKERS] Rename max_parallel_degree?

On Tue, May 31, 2016 at 11:22 AM, Josh berkus wrote: >> I think we can hope that developers are going to be less confused about >> that than users. > > Makes sense. Maybe EXPLAIN doesn't have to use the term parallel worker at all. It can instead use a slightly broader terminology, possibly inclu

Re: [HACKERS] Rename max_parallel_degree?

On Tue, May 31, 2016 at 2:22 PM, Josh berkus wrote: > On 05/31/2016 11:17 AM, Peter Eisentraut wrote: > > On 5/31/16 2:02 PM, Josh berkus wrote: > >> I get where you're coming from, but I think Haas's query plan output is > >> going to show us the confusion we're going to get. So we need to eith

Re: [HACKERS] Rename max_parallel_degree?

Josh berkus writes: > One more consistency question: what's the effect of running out of > max_parallel_workers? ITYM max_worker_processes (ie, the cluster-wide pool size)? > That is, say max_parallel_workers is set to 10, and 8 are already > allocated. If I ask for max_parallel_X = 4, how many

Re: [HACKERS] Rename max_parallel_degree?

On 05/31/2016 11:27 AM, Peter Geoghegan wrote: > On Tue, May 31, 2016 at 11:22 AM, Josh berkus wrote: >>> I think we can hope that developers are going to be less confused about >>> that than users. >> >> Makes sense. > > Maybe EXPLAIN doesn't have to use the term parallel worker at all. It > can

Re: [HACKERS] Rename max_parallel_degree?

On 05/31/2016 11:29 AM, Tom Lane wrote: > Josh berkus writes: >> One more consistency question: what's the effect of running out of >> max_parallel_workers? > > ITYM max_worker_processes (ie, the cluster-wide pool size)? Yes. Sorry for contributing to the confusion. Too many similar-sounding p

Re: [HACKERS] Logic behind parallel default? WAS: Rename max_parallel_degree?

On 05/31/2016 11:10 AM, Tom Lane wrote: > Josh berkus writes: >> Is there a thread on how we determined this default of 2? I can't find >> one under likely search terms. > > The 9.6 open-items list cites > > https://www.postgresql.org/message-id/flat/20160420174631.3qjjhpwsvvx5b...@alap3.anaraz

Re: [HACKERS] Rename max_parallel_degree?

Josh berkus writes: > On 05/31/2016 11:29 AM, Tom Lane wrote: >> Josh berkus writes: >>> One more consistency question: what's the effect of running out of >>> max_parallel_workers? >> ITYM max_worker_processes (ie, the cluster-wide pool size)? > Yes. Sorry for contributing to the confusion.

Re: [HACKERS] Rename max_parallel_degree?

On Tue, May 31, 2016 at 2:37 PM, Josh berkus wrote: > On 05/31/2016 11:27 AM, Peter Geoghegan wrote: > > On Tue, May 31, 2016 at 11:22 AM, Josh berkus wrote: > >>> I think we can hope that developers are going to be less confused about > >>> that than users. > >> > >> Makes sense. > > > > Maybe

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

On 05/31/2016 07:24 PM, Tom Lane wrote: Tomas Vondra writes: On 05/31/2016 06:59 PM, Tom Lane wrote: I'm confused here --- are you speaking of having removed if (msg->cutoff_time > req->request_time) req->request_time = msg->cutoff_time; ? That is not a check for clock

Re: [HACKERS] Rename synchronous_standby_names?

On Tue, May 31, 2016 at 2:19 PM, Peter Eisentraut < peter.eisentr...@2ndquadrant.com> wrote: > On 5/31/16 1:47 PM, Jaime Casanova wrote: > >> Are we going to change synchronous_standby_names? Certainly the GUC is >> not *only* a list of names anymore. >> >> synchronous_standby_config? >> synchrono

Re: [HACKERS] Logic behind parallel default? WAS: Rename max_parallel_degree?

Josh berkus writes: > On 05/31/2016 11:10 AM, Tom Lane wrote: >> The 9.6 open-items list cites >> https://www.postgresql.org/message-id/flat/20160420174631.3qjjhpwsvvx5b...@alap3.anarazel.de > Looks like we didn't decide for the release, just the beta. Indeed. I think it's premature to have thi

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

Tomas Vondra writes: > I've checked how this worked in 9.2 (before the 9.3 patch that split the > file per db), and back then last_statsrequest (transformed to > request_time) was used to decide whether we need to write something. But > now we do that by simply checking whether the list is empt

Re: [HACKERS] Rename max_parallel_degree?

I wrote: > At the risk of opening another can of worms, what about renaming > max_worker_processes as well? It would be a good thing if that > had "cluster" in it somewhere, or something that indicates it's a > system-wide value not a per-session value. "max_workers_per_cluster" > would answer, t

Re: [HACKERS] Rename max_parallel_degree?

On Tue, May 31, 2016 at 3:19 PM, Tom Lane wrote: > I wrote: >> At the risk of opening another can of worms, what about renaming >> max_worker_processes as well? It would be a good thing if that >> had "cluster" in it somewhere, or something that indicates it's a >> system-wide value not a per-ses

Re: [HACKERS] Rename max_parallel_degree?

On Tue, May 31, 2016 at 3:19 PM, Tom Lane wrote: > I wrote: > > At the risk of opening another can of worms, what about renaming > > max_worker_processes as well? It would be a good thing if that > > had "cluster" in it somewhere, or something that indicates it's a > > system-wide value not a pe

Re: [HACKERS] [PATCH][Documination] Add optional USING keyword before opclass name in INSERT statemet

On Tue, May 31, 2016 at 12:34 PM, Tom Lane wrote: > Robert Haas writes: >> On Thu, May 26, 2016 at 3:28 PM, Tom Lane wrote: >>> 99% of the time, you'd be right. But this is an unusual case, for the >>> reasons I mentioned before. > >> I tend to agree with Nikolay. I can't see much upside in ma

Re: [HACKERS] Rename max_parallel_degree?

On Tue, May 31, 2016 at 3:35 PM, Robert Haas wrote: > On Tue, May 31, 2016 at 3:19 PM, Tom Lane wrote: > > I wrote: > >> At the risk of opening another can of worms, what about renaming > >> max_worker_processes as well? It would be a good thing if that > >> had "cluster" in it somewhere, or so

Re: [HACKERS] COMMENT ON, psql and access methods

On Fri, May 27, 2016 at 7:53 AM, Michael Paquier wrote: > As far as I can see, COMMENT ON has no support for access methods. > Wouldn't we want to add it as it is created by a command? On top of > that, perhaps we could have a backslash command in psql to list the > supported access methods, like

Re: [HACKERS] [PATCH][Documination] Add optional USING keyword before opclass name in INSERT statemet

В письме от 31 мая 2016 15:38:38 пользователь Robert Haas написал: > >>> 99% of the time, you'd be right. But this is an unusual case, for the > >>> reasons I mentioned before. > >> > >> I tend to agree with Nikolay. I can't see much upside in making this > >> change. At best, nothing will bre

Re: [HACKERS] Rename max_parallel_degree?

Robert Haas wrote: > Also, I think that we might actually want to add an > additional GUC to prevent the parallel query system from consuming the > entire pool of processes established by max_worker_processes. If > you're doing anything else with worker processes on your system, you > might well

Re: [HACKERS] Rename max_parallel_degree?

On Tue, May 31, 2016 at 12:55 PM, Alvaro Herrera wrote: > Agreed -- things like pglogical and BDR rely on background workers to do > their jobs. Many other users of bgworkers have popped up, so I think > it'd be a bad idea if parallel queries are able to monopolize all the > available slots. Tha

Re: [HACKERS] Perf Benchmarking and regression.

On Fri, May 27, 2016 at 12:37 AM, Andres Freund wrote: > I don't think the situation is quite that simple. By *disabling* backend > flushing it's also easy to see massive performance regressions. In > situations where shared buffers was configured appropriately for the workload > (not the case

Re: [HACKERS] Rename max_parallel_degree?

Alvaro Herrera writes: > Robert Haas wrote: >> So I think in the long run we should have three limits: >> >> 1. Cluster-wide limit on number of worker processes for all purposes >> (currently, max_worker_processes). >> >> 2. Cluster-wide limit on number of worker processes for parallelism >> (do

Re: [HACKERS] Rename max_parallel_degree?

On 05/31/2016 01:04 PM, Tom Lane wrote: > The name should be closely related to what we use for #3. I could go for > max_total_parallel_workers for #2 and max_parallel_workers for #3. > Or maybe max_parallel_workers_total? How about parallel_worker_pool? -- -- Josh Berkus Red Hat OSAS (any opin

Re: [HACKERS] Rename max_parallel_degree?

On Tue, May 31, 2016 at 4:04 PM, Tom Lane wrote: > Alvaro Herrera writes: >> Robert Haas wrote: >>> So I think in the long run we should have three limits: >>> >>> 1. Cluster-wide limit on number of worker processes for all purposes >>> (currently, max_worker_processes). >>> >>> 2. Cluster-wide l

Re: [HACKERS] [PATCH][Documination] Add optional USING keyword before opclass name in INSERT statemet

On Tue, May 31, 2016 at 3:55 PM, Nikolay Shaplov wrote: > В письме от 31 мая 2016 15:38:38 пользователь Robert Haas написал: > > > >>> 99% of the time, you'd be right. But this is an unusual case, for > the > > >>> reasons I mentioned before. > > >> > > >> I tend to agree with Nikolay. I can't

Re: [HACKERS] Rename max_parallel_degree?

Robert Haas wrote: > I just want to point out that if we change #1, we're breaking > postgresql.conf compatibility for, IMHO, not a whole lot of benefit. > I'd just leave it alone. We can add the old name as a synonym in guc.c to maintain compatibility. > I would propose to call #2 max_parallel_

Re: [HACKERS] [GENERAL] Permission Denied Error on pg_xlog/RECOVERYXLOG file

Hi Folks! The permissions on the RECOVERYXLOG file at the time of the error are 0400: -r. 1 postgres postgres 16777216 May 31 09:51 RECOVERYXLOG I sent that info to Tom earlier this afternoon (still learning the posting protocols - sorry) - his response is below: From Tom: Ah, that con

[HACKERS] JSON[B] arrays are second-class citizens

Folks, While querying some JSONB blobs at work in preparation for a massive rework of the data infrastructure, I ran into things that really puzzled me, to wit: SELECT * FROM unnest('["a","b","c"]'::jsonb); ERROR: function unnest(jsonb) does not exist SELECT * FROM jsonb_array_elements('["a","b

Re: [HACKERS] Rename max_parallel_degree?

On Tue, May 31, 2016 at 1:27 PM, Alvaro Herrera wrote: > This is a very good point. > > I think parallel maintenance commands are going to require different > tuning than different queries, and I'd rather have separate parameters > for those things rather than force the same parameter being change

Re: [HACKERS] Rename max_parallel_degree?

On Tue, May 31, 2016 at 4:12 PM, Robert Haas wrote: > On Tue, May 31, 2016 at 4:04 PM, Tom Lane wrote: > > Alvaro Herrera writes: > >> Robert Haas wrote: > >>> So I think in the long run we should have three limits: > >>> > >>> 1. Cluster-wide limit on number of worker processes for all purpose

Re: [HACKERS] JSON[B] arrays are second-class citizens

On Tue, May 31, 2016 at 4:34 PM, David Fetter wrote: > Folks, > > While querying some JSONB blobs at work in preparation for a massive > rework of the data infrastructure, I ran into things that really > puzzled me, to wit: > > SELECT * FROM unnest('["a","b","c"]'::jsonb); > ERROR: function unne

Re: [HACKERS] JSON[B] arrays are second-class citizens

On Tue, May 31, 2016 at 5:06 PM, David G. Johnston < david.g.johns...@gmail.com> wrote: > On Tue, May 31, 2016 at 4:34 PM, David Fetter wrote: > >> Folks, >> >> While querying some JSONB blobs at work in preparation for a massive >> rework of the data infrastructure, I ran into things that really

Re: [HACKERS] JSON[B] arrays are second-class citizens

On Tue, May 31, 2016 at 05:06:00PM -0400, David G. Johnston wrote: > On Tue, May 31, 2016 at 4:34 PM, David Fetter wrote: > > > Folks, > > > > While querying some JSONB blobs at work in preparation for a massive > > rework of the data infrastructure, I ran into things that really > > puzzled me,

Re: [HACKERS] Rename max_parallel_degree?

Alvaro Herrera writes: > Robert Haas wrote: >> I just want to point out that if we change #1, we're breaking >> postgresql.conf compatibility for, IMHO, not a whole lot of benefit. >> I'd just leave it alone. > We can add the old name as a synonym in guc.c to maintain compatibility. I doubt this

Re: [HACKERS] JSON[B] arrays are second-class citizens

On Tue, May 31, 2016 at 5:46 PM, David Fetter wrote: > On Tue, May 31, 2016 at 05:06:00PM -0400, David G. Johnston wrote: > > On Tue, May 31, 2016 at 4:34 PM, David Fetter wrote: > > > > > Folks, > > > > > > While querying some JSONB blobs at work in preparation for a massive > > > rework of the

Re: [HACKERS] JSON[B] arrays are second-class citizens

David Fetter writes: > On Tue, May 31, 2016 at 05:06:00PM -0400, David G. Johnston wrote: >> While likely not that common the introduction of an ambiguity makes >> raises the bar considerably. > What ambiguity? My first thought about it was that select unnest('{1,2,3}'); would start failing.

Re: [HACKERS] Parallel safety tagging of extension functions

On 05/31/2016 06:47 PM, Tom Lane wrote: Given that, your original approach of manually updating proargtypes in the existing pg_proc row for the functions may be the best way. Anything else is going to be more complicated and ultimately will still require at least one direct catalog update. It

Re: [HACKERS] JSON[B] arrays are second-class citizens

The idea of converting a JSONB array to a PG array is appealing and would potentially be more general-purpose than adding a new unnest. I'm not sure how feasible either suggestion is. I will say that I think the current state of affairs is gratuitously verbose and expects users to memorize a subst

Re: [HACKERS] COMMENT ON, psql and access methods

On Wed, Jun 1, 2016 at 4:52 AM, Robert Haas wrote: > On Fri, May 27, 2016 at 7:53 AM, Michael Paquier > wrote: >> As far as I can see, COMMENT ON has no support for access methods. >> Wouldn't we want to add it as it is created by a command? On top of >> that, perhaps we could have a backslash co

Re: [HACKERS] Statement timeout

> FWIW, I think the existing behavior is just fine. It corresponds to what > PQexec has always done with multi-statement query strings; that is, > statement_timeout governs the total time to execute the transaction (the > whole query string, unless you put transaction control commands in there). >

[HACKERS] User demand, and idea, for C-code conversions from JSON arrays to PostgreSQL arrays

All, Oven in the "JSON[B] arrays are second-class citizens" thread [1] I made the observation that the only way to get a PostgreSQL array from a JSON array is via the "elements->cast->array_agg" chain. For JSON arrays that are homogeneous in nature the capability to go "directly" from JSON to jso

  1   2   >