Hello!
Got some strange behavior of random() function:
postgres=# select (select random() ) from generate_series(1,10) as i;
random
---
0.831577288918197
0.831577288918197
0.831577288918197
0.831577288918197
0.831577288918197
0.831577288918197
0.831577288918197
0.83
Hi,
I am testing pgbench with more than 100 connections.
also set max_connection in postgresql.conf more than 100.
Initially pgbench tries to scale nearby 150 but later it come down to 100
connections and stable there.
It this limitation of pgbench? or bug? or i am doing it wrong way?
---
I tes
On Wed, Jun 29, 2016 at 7:43 PM, Alex Ignatov wrote:
> Hello!
>
> Got some strange behavior of random() function:
>
> postgres=# select (select random() ) from generate_series(1,10) as i;
> random
> ---
> 0.831577288918197
> [...]
> (10 rows)
I recall that this is treated a
Hello Sachin,
Your report is very imprecise so it is hard to tell anything.
What version of client and server are you running? On what hardware ? (200
connections => 200 active postgres processes, how many processes per core
are you expecting to run? the recommanded value is about 2 connectio
More specifically...
On Wed, Jun 29, 2016 at 7:34 AM, Michael Paquier
wrote:
> On Wed, Jun 29, 2016 at 7:43 PM, Alex Ignatov
> wrote:
> > Hello!
> >
> > Got some strange behavior of random() function:
> >
> > postgres=# select (select random() ) from generate_series(1,10) as i;
> > random
Hi Fabien,
Sorry for very short report.
I feel pgbench is not so complex tool.
Please see below answers to your questions.
On Wed, Jun 29, 2016 at 5:07 PM, Fabien COELHO wrote:
>
> Hello Sachin,
>
> Your report is very imprecise so it is hard to tell anything.
>
> What version of client and s
Thank you.
On Tue, Jun 28, 2016 at 11:06 PM Oleg Bartunov wrote:
> On Wed, Jun 29, 2016 at 6:17 AM, M Enrique <
> enrique.mailing.li...@gmail.com> wrote:
>
>> What's a good source code entry point to review how this is working for
>> anyarray currently? I am new to the postgres code. I spend som
On 29 June 2016 at 18:47, Sachin Kotwal wrote:
> I am testing pgbench with more than 100 connections.
> also set max_connection in postgresql.conf more than 100.
>
> Initially pgbench tries to scale nearby 150 but later it come down to 100
> connections and stable there.
>
> It this limitation o
On Tue, Jun 28, 2016 at 11:12 PM, Peter Eisentraut
wrote:
> Do this:
>
> CREATE DATABASE test1;
> REVOKE CONNECT ON DATABASE test1 FROM PUBLIC;
>
> Run pg_dumpall.
>
> In 9.5, this produces
>
> CREATE DATABASE test1 WITH TEMPLATE = template0 OWNER = peter;
> REVOKE ALL ON DATABASE test1 FROM PUBLI
* Robert Haas (robertmh...@gmail.com) wrote:
> On Tue, Jun 28, 2016 at 11:12 PM, Peter Eisentraut
> wrote:
> > Do this:
> >
> > CREATE DATABASE test1;
> > REVOKE CONNECT ON DATABASE test1 FROM PUBLIC;
> >
> > Run pg_dumpall.
> >
> > In 9.5, this produces
> >
> > CREATE DATABASE test1 WITH TEMPLATE
On Wed, Jun 29, 2016 at 11:14 AM, Masahiko Sawada wrote:
> On Fri, Jun 24, 2016 at 11:04 AM, Amit Kapila wrote:
>> On Fri, Jun 24, 2016 at 4:33 AM, Andres Freund wrote:
>>> On 2016-06-23 18:59:57 -0400, Alvaro Herrera wrote:
Andres Freund wrote:
> I'm looking into three approaches
Hi,
On Wed, Jun 29, 2016 at 6:29 PM, Craig Ringer wrote:
> On 29 June 2016 at 18:47, Sachin Kotwal wrote:
>
>
>> I am testing pgbench with more than 100 connections.
>> also set max_connection in postgresql.conf more than 100.
>>
>> Initially pgbench tries to scale nearby 150 but later it come
On 29/06/2016 08:51, Amit Kapila wrote:
> On Wed, Jun 29, 2016 at 11:54 AM, Julien Rouhaud
> wrote:
>> Or should we allow setting it to -1 for instance to disable the limit?
>>
>
> By disabling the limit, do you mean to say that only
> max_parallel_workers_per_gather will determine the workers re
On 29.06.2016 15:30, David G. Johnston wrote:
More specifically...
On Wed, Jun 29, 2016 at 7:34 AM, Michael Paquier
mailto:michael.paqu...@gmail.com>>wrote:
On Wed, Jun 29, 2016 at 7:43 PM, Alex Ignatov
mailto:a.igna...@postgrespro.ru>> wrote:
> Hello!
>
> Got some strange
[ Please do not quote the entire thread in each followup. That's
disrespectful of your readers' time, and will soon cause people to
stop reading the thread, meaning you don't get answers. ]
Alex Ignatov writes:
> In this subquery(below) we have reference to outer variables but it is
> not worki
We may also want to consider handling abstract events such as
"tuples-are-available-at-plan-node-X".
One benefit is : we can combine this with batch processing. For e.g. in
case of an Append node containing foreign scans, its parent node may not
want to process the Append node result until Append
"David G. Johnston" writes:
> A correlated subquery, on the other hand, has to be called once for every
> row and is evaluated within the context supplied by said row. Each time
> random is called it returns a new value.
> Section 4.2.11 (9.6 docs)
> https://www.postgresql.org/docs/9.6/static/sq
On Wed, Jun 29, 2016 at 8:36 AM, Sachin Kotwal wrote:
> postgresql does not give any error.
>
> pgbench says:
> client 36 aborted in state 2: ERROR: could not connect to server "server_1"
> DETAIL: FATAL: sorry, too many clients already
The error message that you are seeing there "FATAL: sorry
On Fri, Jun 24, 2016 at 2:23 PM, Flavius Anton wrote:
> Any other thoughts on this? My guess is that it might be an important
> addition to Postgres that can attract even more users, but I am not
> sure if there's enough interest from the community. If I want to pick
> this task, how should I move
On Wed, Jun 29, 2016 at 5:36 AM, Sachin Kotwal wrote:
> Hi Fabien,
>
> Sorry for very short report.
> I feel pgbench is not so complex tool.
>
> Please see below answers to your questions.
>
>
> On Wed, Jun 29, 2016 at 5:07 PM, Fabien COELHO wrote:
>>
>>
>> Hello Sachin,
>>
>> Your report is very
On Sat, Jun 25, 2016 at 3:44 AM, Andreas Karlsson wrote:
> On 06/24/2016 01:31 PM, David Rowley wrote:
>> Seems there's a small error in the upgrade script for citext for 1.1
>> to 1.2 which will cause min(citext) not to be parallel enabled.
>>
>> max(citext)'s combinefunc is first set incorrectly
Peter,
* Peter Eisentraut (peter.eisentr...@2ndquadrant.com) wrote:
> Do this:
>
> CREATE DATABASE test1;
> REVOKE CONNECT ON DATABASE test1 FROM PUBLIC;
>
> Run pg_dumpall.
>
> In 9.5, this produces
>
> CREATE DATABASE test1 WITH TEMPLATE = template0 OWNER = peter;
> REVOKE ALL ON DATABASE te
On Mon, Jun 27, 2016 at 6:04 PM, Tom Lane wrote:
> Robert Haas writes:
>> On Mon, Jun 27, 2016 at 5:28 PM, Tom Lane wrote:
>>> Seems to me that it should generally be the case that consider_parallel
>>> would already be clear on the parent rel if the tlist isn't parallel safe,
>>> and if it isn'
Hello Hackers.
I decided to talk about the current state of the project:
1. Merge with 9.6 master.
2. plpython2, plpython3, plperl, pltcl, plsql all work correctly (all tests
pass).
3. Works done for all contrib modules.
4. You can use gettext, .po->.mo will have converted by CMake.
5. All t
Hello,
I am testing it with 9.6-beta1 binaries. For server and client it is same.
I am using pgbench on top of postgres_fdw.
Hmmm... So pgbench is connected to some pg instance, and this pg instance
is connected to something else on another host? Or to the same instance,
in which case you w
On Tue, Jun 28, 2016 at 10:10 PM, Peter Eisentraut
wrote:
> On 6/27/16 5:37 PM, Robert Haas wrote:
>> Please find attached an a patch for a proposed alternative approach.
>> This does the following:
>>
>> 1. When the client_encoding GUC is changed in the worker,
>> SetClientEncoding() is not calle
On Mon, Jun 27, 2016 at 11:40 PM, Michael Paquier
wrote:
> On Tue, Jun 28, 2016 at 6:49 AM, Robert Haas wrote:
>> On Sun, Jun 26, 2016 at 6:19 AM, Piotr Stefaniak
>> wrote:
while investigating the shm_mq code and its testing module I made some
cosmetic improvements there. You can see t
On 2016-06-29 19:04:31 +0530, Amit Kapila wrote:
> There is nothing in this record which recorded the information about
> visibility clear flag.
I think we can actually defer the clearing to the lock release? A tuple
being locked doesn't require the vm being cleared.
> I think in this approach,
Robert Haas writes:
> On Mon, Jun 27, 2016 at 6:04 PM, Tom Lane wrote:
>> Huh? The final tlist would go with the final_rel, ISTM, not the scan
>> relation. Maybe we have some rejiggering to do to make that true, though.
> Mumble. You're right that there are two rels involved, but I think
> I'
On Wed, Jun 29, 2016 at 1:26 PM, Tom Lane wrote:
> Robert Haas writes:
>> On Mon, Jun 27, 2016 at 6:04 PM, Tom Lane wrote:
>>> Huh? The final tlist would go with the final_rel, ISTM, not the scan
>>> relation. Maybe we have some rejiggering to do to make that true, though.
>
>> Mumble. You're
On Wed, Jun 29, 2016 at 12:23 PM, Alvaro Herrera
wrote:
> Michael Paquier wrote:
>> On Wed, Jun 29, 2016 at 6:42 AM, Alvaro Herrera
>> wrote:
>
>> > I have already edited the patch following some of these ideas. Will
>> > post a new version later.
>>
>> Cool, thanks.
>
> Here it is. I found it
Fujii Masao wrote:
> On Wed, Jun 29, 2016 at 12:23 PM, Alvaro Herrera
> wrote:
> > Michael Paquier wrote:
> >> On Wed, Jun 29, 2016 at 6:42 AM, Alvaro Herrera
> >> wrote:
> >
> >> > I have already edited the patch following some of these ideas. Will
> >> > post a new version later.
> >>
> >> Coo
On Thu, Jun 30, 2016 at 2:50 AM, Alvaro Herrera
wrote:
> Fujii Masao wrote:
>> On Wed, Jun 29, 2016 at 12:23 PM, Alvaro Herrera
>> wrote:
>> > Michael Paquier wrote:
>> >> On Wed, Jun 29, 2016 at 6:42 AM, Alvaro Herrera
>> >> wrote:
>> >
>> >> > I have already edited the patch following some of
Fujii Masao wrote:
> On Thu, Jun 30, 2016 at 2:50 AM, Alvaro Herrera
> wrote:
> > Fujii Masao wrote:
> >> On Wed, Jun 29, 2016 at 12:23 PM, Alvaro Herrera
> >> wrote:
> >> > Michael Paquier wrote:
> >> >> On Wed, Jun 29, 2016 at 6:42 AM, Alvaro Herrera
> >> >> wrote:
> >> >
> >> >> > I have alre
Hi,
On 2016-06-28 10:01:28 +, Rajeev rastogi wrote:
> >3) Our 1-by-1 tuple flow in the executor has two major issues:
>
> Agreed, In order to tackle this IMHO, we should
> 1. Makes the processing data-centric instead of operator centric.
> 2. Instead of pulling each tuple from immediate oper
Shawn wrote:
> Unfortunately...no. I have been trying to repro this scenario. Is there a
> specific way to make a Python connection where this is possible?
>
> My end game, if this is not something that can be fixed on the Postgres
> side, is to come up with a way to automatically cause the conn
Oleg Bartunov writes:
>> On Tue, Jun 28, 2016 at 9:32 AM, Noah Misch wrote:
> This PostgreSQL 9.6 open item now needs a permanent owner. Would any other
> committer like to take ownership? I see Teodor committed some things relevant
> to this item just today, so the task may be as simple as ver
> "Tom" == Tom Lane writes:
> Tomas Vondra writes:
>> Attached is a reworked patch, mostly following the new design proposal
>> from this thread.
Tom> Comments and testing appreciated.
This blows up (see bug 14219 for testcase) in
match_foreign_keys_to_quals on the find_base_rel call(
Andrew Gierth writes:
> If the query was produced by rule expansion then the code that populates
> fkinfo includes FK references to the OLD and NEW RTEs, but those might not
> appear in the jointree (the testcase for the bug is a DELETE rule where
> NEW clearly doesn't apply) and hence build_simpl
Yury Zhuravlev wrote:
> Hello Hackers.
>
> I decided to talk about the current state of the project:
> 1. Merge with 9.6 master. 2. plpython2, plpython3, plperl, pltcl, plsql all
> work correctly (all tests pass).
> 3. Works done for all contrib modules. 4. You can use gettext, .po->.mo will
> hav
On 2016-06-29 18:58, Robert Haas wrote:
This code predates be7558162acc5578d0b2cf0c8d4c76b6076ce352, prior to
which proc_exit(0) forced an immediate, unconditional restart. It's
true that, given that commit, changing this code to do proc_exit(0)
instead of proc_exit(1) would be harmless. Howeve
Alvaro Herrera wrote:
> I propose to push this patch, closing the open item, and you can rework
> on top -- I suppose you would completely remove the original conninfo
> from shared memory and instead only copy the obfuscated version there
> (and probably also remove the ready_to_display flag). I
On Thu, Jun 30, 2016 at 6:01 AM, Alvaro Herrera
wrote:
> Alvaro Herrera wrote:
>
>> I propose to push this patch, closing the open item, and you can rework
>> on top -- I suppose you would completely remove the original conninfo
>> from shared memory and instead only copy the obfuscated version th
On Wed, Jun 29, 2016 at 11:18 PM, Michael Paquier wrote:
> On Thu, Jun 30, 2016 at 6:01 AM, Alvaro Herrera
> wrote:
> > Alvaro Herrera wrote:
> >
> >> I propose to push this patch, closing the open item, and you can rework
> >> on top -- I suppose you would completely remove the original conninf
Magnus Hagander writes:
> There was also that (old) thread about making the recovery.conf parameters
> be general GUCs. I don't actually remember the consensus there, but diong
> that would certainly change how it's handled as well.
It strikes me that keeping a password embedded in the conninfo f
On Thu, Jun 30, 2016 at 6:47 AM, Tom Lane wrote:
> Magnus Hagander writes:
>> There was also that (old) thread about making the recovery.conf parameters
>> be general GUCs. I don't actually remember the consensus there, but diong
>> that would certainly change how it's handled as well.
>
> It str
On Sat, Jun 25, 2016 at 6:40 PM, Tom Lane wrote:
>
> If that is the explanation, I'm suspicious that it's got something to do
> with the interaction of a static inline-able (single-call-site) function
> and taking the address of a formal parameter. We certainly have multiple
> other instances of
On 29 June 2016 at 21:49, Sachin Kotwal wrote:
> Hi,
>
>
> On Wed, Jun 29, 2016 at 6:29 PM, Craig Ringer
> wrote:
>
>> On 29 June 2016 at 18:47, Sachin Kotwal wrote:
>>
>>
>>> I am testing pgbench with more than 100 connections.
>>> also set max_connection in postgresql.conf more than 100.
>>>
On 30 June 2016 at 02:32, Andres Freund wrote:
>
> Hi,
>
> On 2016-06-28 10:01:28 +, Rajeev rastogi wrote:
> > >3) Our 1-by-1 tuple flow in the executor has two major issues:
> >
> > Agreed, In order to tackle this IMHO, we should
> > 1. Makes the processing data-centric instead of operator c
Michael Paquier writes:
> On Thu, Jun 30, 2016 at 6:47 AM, Tom Lane wrote:
>> It strikes me that keeping a password embedded in the conninfo from being
>> exposed might be quite a bit harder/riskier if it became a GUC. Something
>> to keep in mind if we ever try to make that change ...
> Exposi
"Haroon ." writes:
> On Sat, Jun 25, 2016 at 6:40 PM, Tom Lane wrote:
>> This leads to a couple of suggestions for dodging the problem:
>>
>> 2. Don't pass the original formal parameter to
>> get_foreign_key_join_selectivity, ie do something like
>>
>> static double
>> calc_joinrel_size_estimat
Tom Lane wrote:
> "Haroon ." writes:
> > The problem appears to be related to 'taking the address of a formal
> > parameter'. NOT passing the original formal parameter to
> > get_foreign_key_join_selectivity fixes it (dodges the problem) on VS2013.
>
> Thanks for investigating! I'll go commit t
Michael Paquier wrote:
> On Fri, Jun 24, 2016 at 11:51 AM, Tsunakawa, Takayuki
> wrote:
> >> From: pgsql-hackers-ow...@postgresql.org
> >> [mailto:pgsql-hackers-ow...@postgresql.org] On Behalf Of Michael Paquier
> >> Sent: Friday, June 24, 2016 11:37 AM
> >> On Fri, Jun 24, 2016 at 11:33 AM, Craig
Alvaro Herrera writes:
> Tom Lane wrote:
>> Thanks for investigating! I'll go commit that change. I wish someone
>> would put up a buildfarm critter using VS2013, though.
> Uh, isn't that what woodlouse is using?
Well, it wasn't reporting this crash, so there's *something* different.
On Mon, Jun 27, 2016 at 4:49 PM, Tom Lane wrote:
> A few specific comments:
>
> * Can't we remove wholePlanParallelSafe altogether, in favor of just
> examining best_path->parallel_safe in standard_planner?
>
> * In grouping_planner, I'm not exactly convinced that
> final_rel->consider_parallel ca
On Wed, Jun 29, 2016 at 4:35 PM, Piotr Stefaniak
wrote:
> On 2016-06-29 18:58, Robert Haas wrote:
>> This code predates be7558162acc5578d0b2cf0c8d4c76b6076ce352, prior to
>> which proc_exit(0) forced an immediate, unconditional restart. It's
>> true that, given that commit, changing this code to
On 30 June 2016 at 07:21, Tom Lane wrote:
> Alvaro Herrera writes:
> > Tom Lane wrote:
> >> Thanks for investigating! I'll go commit that change. I wish someone
> >> would put up a buildfarm critter using VS2013, though.
>
> > Uh, isn't that what woodlouse is using?
>
> Well, it wasn't reporti
On Wed, Jun 29, 2016 at 11:54 AM, Julien Rouhaud
wrote:
> On 29/06/2016 06:29, Amit Kapila wrote:
>> On Wed, Jun 29, 2016 at 2:57 AM, Julien Rouhaud
>> wrote:
>>>
>>> Thanks a lot for the help!
>>>
>>> PFA v6 which should fix all the issues mentioned.
>>
>> Couple of minor suggestions.
>>
>> -
I'm happy with this patch.
On 6/29/16 12:41 PM, Robert Haas wrote:
On Tue, Jun 28, 2016 at 10:10 PM, Peter Eisentraut
wrote:
On 6/27/16 5:37 PM, Robert Haas wrote:
Please find attached an a patch for a proposed alternative approach.
This does the following:
1. When the client_encoding GUC i
On Wed, Jun 29, 2016 at 10:30 PM, Andres Freund wrote:
> On 2016-06-29 19:04:31 +0530, Amit Kapila wrote:
>> There is nothing in this record which recorded the information about
>> visibility clear flag.
>
> I think we can actually defer the clearing to the lock release?
How about the case if aft
On 2016-06-30 08:59:16 +0530, Amit Kapila wrote:
> On Wed, Jun 29, 2016 at 10:30 PM, Andres Freund wrote:
> > On 2016-06-29 19:04:31 +0530, Amit Kapila wrote:
> >> There is nothing in this record which recorded the information about
> >> visibility clear flag.
> >
> > I think we can actually defer
On Thu, Jun 30, 2016 at 5:10 AM, Alvaro Herrera
wrote:
> Yury Zhuravlev wrote:
>> Hello Hackers.
>>
>> I decided to talk about the current state of the project:
>> 1. Merge with 9.6 master. 2. plpython2, plpython3, plperl, pltcl, plsql all
>> work correctly (all tests pass).
>> 3. Works done for a
On 21/06/16 03:53, Mark Dilger wrote:
On Jun 18, 2016, at 5:48 PM, Josh Berkus wrote:
On 06/16/2016 11:01 PM, Craig Ringer wrote:
I thought about raising this, but I think in the end it's replacing one
confusing and weird versioning scheme for another confusing and weird
versioning scheme.
It
On Thu, Jun 30, 2016 at 9:13 AM, Andres Freund wrote:
> On 2016-06-30 08:59:16 +0530, Amit Kapila wrote:
>> On Wed, Jun 29, 2016 at 10:30 PM, Andres Freund wrote:
>> > On 2016-06-29 19:04:31 +0530, Amit Kapila wrote:
>> >> There is nothing in this record which recorded the information about
>> >>
64 matches
Mail list logo
