At Tue, 31 May 2016 12:29:50 -0400, Tom Lane wrote in
<7445.1464712...@sss.pgh.pa.us>
> 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
On 2016/05/31 14:53, Amit Langote wrote:
On 2016/05/30 22:59, Craig Ringer wrote:
On 30 May 2016 at 16:17, Etsuro Fujita wrote:
That's a good point, but the basic idea is to send the local query
almost-as-is to the remote server if possible. For example, if the local
query is "INSERT INTO f
On 1 June 2016 at 13:09, Tsunakawa, Takayuki wrote:
> From: pgsql-hackers-ow...@postgresql.org [mailto:
> pgsql-hackers-ow...@postgresql.org] On Behalf Of Craig Ringer
>
> While that's probably OK, it's not especially desirable. The typical
> Windows deployment model involves the application bund
From: pgsql-hackers-ow...@postgresql.org
[mailto:pgsql-hackers-ow...@postgresql.org] On Behalf Of Craig Ringer
While that's probably OK, it's not especially desirable. The typical Windows
deployment model involves the application bundling all its direct dependencies
except when those are provide
On 1 June 2016 at 08:33, Tatsuo Ishii wrote:
> > 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, u
On 30 May 2016 at 11:04, Tsunakawa, Takayuki <
tsunakawa.ta...@jp.fujitsu.com> wrote:
> Hello,
>
> I'd like to ask you about the policy of application binary compatibility.
> And have a suggestion as well.
>
> QUESTION
> ==
>
> My customer asked me
Hi,
In PostgreSQL , does the order in which the criteria is given matter ??
For example
Query 1 : Select * from TABLE where a > 5 and b < 10;
Query 2 : Select * from TABLE where b <10 and a > 5;
Are query 1 and query 2 the same in PostgreSQL or different ?? If its
different , WHY ??
Than
On 1 June 2016 at 11:48, Michael Paquier wrote:
> Could it be possible to mark PostmasterPid with PGDLLIMPORT on HEAD
> and back-branches?
>
Sounds sensible to me.
--
Craig Ringer http://www.2ndQuadrant.com/
PostgreSQL Development, 24x7 Support, Training & Services
Hi all,
While hacking a background worker for Windows/Linux that is sending
signals to the Postmaster depending on the state of the server where
Postgres is running (particularly after a certain size threshold is
reached on the partition of PGDATA SIGINT is sent to PostmasterPid to
have it stop cl
> From: Michael Meskes [mailto:mes...@postgresql.org]
> e.g. a random hit from google:=C2=A0https://www.bottomupcs.com/libra
> ries_and_the_linker.xhtml
>
> There even is a wikipedia page about
> it:=C2=A0https://en.wikipedia.org/wiki/
> Soname
Thank you for good pointers. The former is particul
On Tue, May 31, 2016 at 10:23 PM, Tom Lane wrote:
> Noah Misch writes:
>> On Tue, May 31, 2016 at 10:09:05PM -0400, Robert Haas wrote:
>>> What I *think* is going on here is:
>>> - ac1d794 lowered performance
>>> - backend_flush_after with a non-zero default lowered performance with
>>> a vengean
On Sun, May 29, 2016 at 01:31:24AM -0400, Noah Misch wrote:
> On Sun, May 15, 2016 at 12:53:13PM +, Clément Prévost wrote:
> > On Mon, May 9, 2016 at 4:50 PM Andres Freund wrote:
> > > I think it's a good idea to run a force-parallel run on some buildfarm
> > > members. But I'm rather convince
On Sun, May 29, 2016 at 1:44 AM, Noah Misch wrote:
> On Fri, May 06, 2016 at 04:42:48PM -0400, Robert Haas wrote:
>> On Thu, May 5, 2016 at 2:20 PM, Andres Freund wrote:
>> > On 2016-05-02 14:48:18 -0700, Andres Freund wrote:
>> > + charnew_vmbuf[BLCKSZ];
>> > +
Noah Misch writes:
> On Tue, May 31, 2016 at 10:09:05PM -0400, Robert Haas wrote:
>> What I *think* is going on here is:
>> - ac1d794 lowered performance
>> - backend_flush_after with a non-zero default lowered performance with
>> a vengeance
>> - 98a64d0 repaired the damage done by ac1d794, or mu
On Tue, May 31, 2016 at 10:09:05PM -0400, Robert Haas wrote:
> On Sun, May 29, 2016 at 1:40 AM, Noah Misch wrote:
> > On Fri, Dec 25, 2015 at 08:08:15PM +0300, Васильев Дмитрий wrote:
> >> I suddenly found commit ac1d794 gives up to 3 times performance
> >> degradation.
> >>
> >> I tried to run p
On Tue, May 31, 2016 at 10:13 PM, Tom Lane wrote:
> Robert Haas writes:
>> On Tue, May 31, 2016 at 10:02 PM, Tom Lane wrote:
>>> The reloption does not set an exact value, according to the code:
>
>> True, max_parallel_degree is an overriding limit. But the point is
>> that, without the relopti
Robert Haas writes:
> On Tue, May 31, 2016 at 10:02 PM, Tom Lane wrote:
>> The reloption does not set an exact value, according to the code:
> True, max_parallel_degree is an overriding limit. But the point is
> that, without the reloption, you can't get lots of workers on a small
> table. The
On Fri, May 27, 2016 at 10:36 PM, Amit Kapila wrote:
> On Sat, May 28, 2016 at 12:28 AM, Andres Freund wrote:
>> contain_volatile_functions_walker is duplicated, near entirely, in
>> contain_volatile_functions_not_nextval_walker.
>
> Previously, I also had same observation.
>
>> Wouldn't it have
On Tue, May 31, 2016 at 10:02 PM, Tom Lane wrote:
> Robert Haas writes:
>> Now, this case is a little trickier. If we called it simply
>> parallel_degree rather than max_parallel_degree, then it would have
>> the same name as the reloption. But the reloption sets an exact
>> value, and the GUC
On Sun, May 29, 2016 at 1:40 AM, Noah Misch wrote:
> On Fri, Dec 25, 2015 at 08:08:15PM +0300, Васильев Дмитрий wrote:
>> I suddenly found commit ac1d794 gives up to 3 times performance degradation.
>>
>> I tried to run pgbench -s 1000 -j 48 -c 48 -S -M prepared on 70 CPU-core
>> machine:
>> commi
Robert Haas writes:
> Now, this case is a little trickier. If we called it simply
> parallel_degree rather than max_parallel_degree, then it would have
> the same name as the reloption. But the reloption sets an exact
> value, and the GUC sets a cap, which is a significant difference.
The relop
On Tue, May 31, 2016 at 8:51 PM, Peter Eisentraut
wrote:
> On 5/31/16 4: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?
>
> Most cluster
On Tue, May 31, 2016 at 5:58 PM, Tom Lane wrote:
> 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
On Wed, Jun 1, 2016 at 6:03 AM, Tatsuo Ishii wrote:
>
> From the document about statement_timeout (config.sgml):
>
> Abort any statement that takes more than the specified number of
> milliseconds, starting from the time the command arrives at the
server
> from the client.
> From: pgsql-hackers-ow...@postgresql.org
> [mailto:pgsql-hackers-ow...@postgresql.org] On Behalf Of Marco Atzeri
> on cygwin the postgresql binary package already include the library
> versions:
>
>/usr/bin/cygecpg-6.dll
>/usr/bin/cygecpg_compat-3.dll
>/usr/bin/cygpgtypes-3.dll
>
On 5/31/16 4: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?
Most cluster-wide settings like this are named max_something
(max_connections, m
On Wed, Jun 1, 2016 at 3:56 AM, David G. Johnston
wrote:
> On Tue, May 31, 2016 at 2:19 PM, Peter Eisentraut
> 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.
>>>
>>> sync
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
> 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).
>
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
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
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
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.
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
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
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,
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
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
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
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
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
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
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_
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
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
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
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
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
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
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
В письме от 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
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
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
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
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
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
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
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
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
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
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
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
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.
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
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
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
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
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
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
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
"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"?
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,
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
"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
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
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
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
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
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.
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
-
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.
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
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.
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
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 ...
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
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
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)
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
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
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
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
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
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
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
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
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
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
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.
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
1 - 100 of 127 matches
Mail list logo
