On Wed, 15 Jul 2020 at 04:01, Marc Millas wrote:
> your answer helps me understand my first problem.
> so, I rewrote a simple loop so as to avoid the "volatile" behaviour.
Not sure what you're trying to do with the plpgsql, but you can just
escape the multiple evaluations by putting the volatile
"David G. Johnston" writes:
> On Tuesday, July 14, 2020, Julie Nishimura wrote:
>> Hello, we currently have 9.4 hot_standby master-slave pair. Going forward,
>> we can keep only one server. How can I convert the system properly?
> If you are keeping the primary you shouldn’t have to do
On Tuesday, July 14, 2020, Julie Nishimura wrote:
> Hello, we currently have 9.4 hot_standby master-slave pair. Going forward,
> we can keep only one server. How can I convert the system properly?
>
If you are keeping the primary you shouldn’t have to do anything. The
absence of a secondary
Hello, we currently have 9.4 hot_standby master-slave pair. Going forward, we
can keep only one server. How can I convert the system properly?
These are some snippets from master postgresql.conf file:
==
wal_level = hot_standby # minimal, archive,
Thanks, for the time being we're looking at using something other than the
FDW for this task.
--
Mike Nolan
On 7/14/20 9:01 AM, Marc Millas wrote:
Hi,
your answer helps me understand my first problem.
so, I rewrote a simple loop so as to avoid the "volatile" behaviour.
(at least I was thinking I did... looks like I was wrong !)
step by step loop:
DO $$
BEGIN
FOR counter IN 1..1000 LOOP
begin
Radoslav Nedyalkov writes:
> Ah, I could have messed up the examples I gave. Row numbers are different.
> Once again the plans , sorry about that.
Given that it works at 100 entries and not 101, I can't escape the
suspicion that you're being burnt by predtest.c's MAX_SAOP_ARRAY_SIZE
limit.
=?UTF-8?Q?Eudald_Valc=C3=A0rcel_Lacasa?= writes:
> I'm running a docker container that executes a php script running a
> sequence of queries.
> One of the queries gets stuck (takes more than 2 hours in execution,
> active in pg_stat_activity).
> The query is executed with a JOIN between a FOREIGN
Hello!
I'm running a docker container that executes a php script running a
sequence of queries.
One of the queries gets stuck (takes more than 2 hours in execution,
active in pg_stat_activity).
The query is executed with a JOIN between a FOREIGN TABLE and a local table.
Executing this query from
Ah, I could have messed up the examples I gave. Row numbers are different.
Once again the plans , sorry about that.
-- 200 entries
Gather (cost=1000.00..106905910.97 rows=7893 width=8)
Workers Planned: 2
-> Parallel Seq Scan on te (cost=0.00..106904121.67 rows=3289 width=8)
On 7/14/20 10:03 AM, Michael Nolan wrote:
An application I wrote is being modified by our development team to use
a FDW to a remote MySQL table instead of the postgresql table for a query.
We're getting this error in the logs periodically. Maybe about once
every 50,000 queries:
2020-07-14
Hi Tom,
a few tests later.
Looks like when you add a partition as default, all tupples of it are read,
even if there is an index on the column that is the partition key.
this do explain our attach time. We are going to clean the default
partition...
regards,
Marc MILLAS
Senior Architect
rows=3832
rows=3870
Your estimate changed very little when you included 100 values vs 200
values. That is interesting to me.
What does the below query give you? How many of those 200 values are found
in the MCVs list? If n_distinct is low, and most of the values are NOT in
the most common value
Hi,
thanks for the answer.
the pb is that the fact table do have mods for "old" data.
so the current scheme implies to truncate partitions and recreate them, and
copy from ods to dm, etc which is better than millions (tens of) delete and
vacuuming.
and so, the partitioning scheme is based on day s
Hi Forum,
I'm scratching my head around the following case:
*te* is a 80M rows, 100GB table. It is a bare simple select over indexed
attribute of it.
EXPLAIN SELECT te.id FROM te WHERE te.current_pid IN (240900026,
240900027,
240900028,
-- 200 entries ...
Gather (cost=1000.00..61517367.85
Marc Millas writes:
> We would like to understand where an alter table attach partition spend its
> time.
> to my understanding, explain doesnt do this.
Nope :-(. As our DDL commands have gotten more complicated, there's
been some discussion of adding that, but nothing's really been done
yet.
An application I wrote is being modified by our development team to use a
FDW to a remote MySQL table instead of the postgresql table for a query.
We're getting this error in the logs periodically. Maybe about once every
50,000 queries:
2020-07-14 11:35:22.799 CDT uscf ::1 ERROR: failed to
On Tue, Jul 14, 2020 at 09:27:56PM +0530, Vishwa Kalyankar wrote:
> HI,
>
> OS cache is updated and I had run the query few times with almost the same
> result each time.
>
> Regards,
> Vishwa
Hi Vishwa,
What are the CPU speeds, memory bandwidth, I/O bandwidth? Often the
lower core count CPUs
Hi,
We would like to understand where an alter table attach partition spend its
time.
to my understanding, explain doesnt do this.
for a BI job we have a partitionned table with 1800+ partitions.
the feeding process of this table leeds to detach and attach partitions.
attaching do take time,
Please don't top-post. Inline (with trim) is better but at minimum
bottom-post.
On Tue, Jul 14, 2020 at 9:01 AM Marc Millas wrote:
> Hi,
> your answer helps me understand my first problem.
> so, I rewrote a simple loop so as to avoid the "volatile" behaviour.
> (at least I was thinking I
Hi,
your answer helps me understand my first problem.
so, I rewrote a simple loop so as to avoid the "volatile" behaviour.
(at least I was thinking I did... looks like I was wrong !)
step by step loop:
DO $$
BEGIN
FOR counter IN 1..1000 LOOP
begin
declare
id1 integer =ceiling(random()*2582);
id3
HI,
OS cache is updated and I had run the query few times with almost the same
result each time.
Regards,
Vishwa
On Tue, Jul 14, 2020 at 6:16 PM Philip Semanchuk <
phi...@americanefficient.com> wrote:
>
>
> > On Jul 14, 2020, at 5:27 AM, Vishwa Kalyankar <
> vishwakalyank...@gmail.com> wrote:
On Tue, Jul 14, 2020 at 8:25 AM David Gasa i Castell
wrote:
> And my surprise went when I see the connection done while there is no user
> granted to connect the database...
>
https://www.postgresql.org/docs/12/ddl-priv.html
"""
PostgreSQL grants privileges on some types of objects to PUBLIC
Ok, thanks for the clarification.
Marc MILLAS
Senior Architect
+33607850334
www.mokadb.com
On Tue, Jul 14, 2020 at 5:24 PM David G. Johnston <
david.g.johns...@gmail.com> wrote:
> On Tue, Jul 14, 2020 at 8:15 AM Marc Millas
> wrote:
>
>> select id, prenom from prenoms where
Hi guys,
I don't know if what I'm going to explain you could be regarded as a
regular behaviour related issue... but I'm so surprised.
I'm working under the latest stable PostgreSQL version 12.3.
$ sudo /usr/lib/postgresql/12/bin/postgres --version
postgres (PostgreSQL) 12.3 (Debian
On Tue, Jul 14, 2020 at 8:15 AM Marc Millas wrote:
> select id, prenom from prenoms where id=ceiling(random()*2582);
>
> expecting to get, allways, one line.
> But its not the case.
> around 15% of time I get 0 lines which is already quite strange to me.
> but 10% of time, I get a random number
Hi,
when, in psql, on a postgres 12.3, I write:
select ceiling(random()*2582);
it does provide the expected answer, ie. a number between 1 and 2582,
inclusive.
allways.
when I decide to use this to get a random row within a table prenoms having
2 columns
a id serial, and a prenom varchar, with
And please be sure that default permissions are defined properly. Otherwise it
may happen that userA creates a new table but userB has access for that.
Alternative option is that user has to grant proper access for the role group
after every time when a new db object is created.
Toomas
> On
Thank for your answer David.
This is what I'll do.
De : David G. Johnston
Envoyé : 13 juillet 2020 19:46
À : Jean-Philippe Chenel
Cc : pgsql-general@lists.postgresql.org
Objet : Re: Both side privileges
On Mon, Jul 13, 2020 at 4:42 PM Jean-Philippe Chenel
Shantanu Shekhar schrieb am 14.07.2020 um 14:34:
> We are upgrading our Postgres instance from 9.6.11 to 10.11. Then as
> part of a second upgrade we will go from 10.11 to 11.6. Currently
> (with 9.6.11) we are using the 42.2.1 JDBC driver. I am trying to
> figure out the impact our database
> On Jul 14, 2020, at 5:27 AM, Vishwa Kalyankar
> wrote:
>
> Hi,
>
> I have two machines - one with 8GB RAM & 4core CPU and the other with 64GB
> Ram & 24 core CPU. Both machines have the same DB (Postgres 12 + Postgis
> 2.5.3). Same query is taking less time in low end machine
We are upgrading our Postgres instance from 9.6.11 to 10.11. Then as part of a
second upgrade we will go from 10.11 to 11.6. Currently (with 9.6.11) we are
using the 42.2.1 JDBC driver. I am trying to figure out the impact our database
upgrade will have on the JDBC driver version but I cannot
Hello Postgres Support Team,
Today we have an outage, our DB was wend down due to 100% space full at FS. We
added space and could able to bring the cluster.
DB version: psql (PostgreSQL) 10.12
OS version : Red Hat Enterprise Linux Server release 7.8 (Maipo)
[0]postgres@axmdevhkdb008$
Hi,
I have two machines - one with 8GB RAM & 4core CPU and the other with 64GB
Ram & 24 core CPU. Both machines have the same DB (Postgres 12 + Postgis
2.5.3). Same query is taking less time in low end machine whereas more
time in high end machine. Any thoughts on where to look? I have tuned
On Mon, 2020-07-13 at 13:01 +0530, Rama Krishnan wrote:
> I m preparing for interview one of the recruiter asked me mvcc drawbacks as i
> told due
> to mvcc it use more space and need to perform maintenance activity.
Yes. Generally speaking, you have to pay a price for keeping old versions of
35 matches
Mail list logo
