Re: PG11.2 - wal_level =minimal max_wal_senders = 0

On Wed, Sep 4, 2019 at 10:44 PM Jason Ralph wrote: > > Thank you Luca, > Can I ask one more related question, I have no need for replication as noted > below, can I safely disable the worker process via the setting below? In my > sandbox it does turn off the logical replication launcher, I just

Re: floating point output

On 9/4/19 5:23 PM, Rob Sargent wrote: I've found the description of floating point types (here ), but I'm looking for the rationale of the output format, particularly with respect to total digits presented (variable in a s

floating point output

I've found the description of floating point types (here ), but I'm looking for the rationale of the output format, particularly with respect to total digits presented (variable in a single select's output) and the droppin

Re: Running a Simple Update Statement Fails, Second Time Suceeds.

On 9/4/19 8:02 AM, Kumar, Virendra wrote: Here is function code: Table definition is below: -- product_master_fdw=# \d product_owner.external_sys_class_code_pres; Table "product_owner.external_sys_class_code_pres" Column|Type

RE: PG11.2 - wal_level =minimal max_wal_senders = 0

Thank you Luca, Can I ask one more related question, I have no need for replication as noted below, can I safely disable the worker process via the setting below? In my sandbox it does turn off the logical replication launcher, I just wanted to be sure I am not affecting anything other than repl

Re: PG11.2 - wal_level =minimal max_wal_senders = 0

On Wed, Sep 4, 2019 at 5:15 PM Jason Ralph wrote: > The question I have is, for a production database not doing replication, can > I safely set the following parameters, I understand that minimal will also > disable wal_archiving so I am concerned about that as well. > > wal_level = minimal > >

Re: Running a Simple Update Statement Fails, Second Time Suceeds.

"Kumar, Virendra" writes: > Here is function code: Hm, nothing very exciting in there. But the known reasons for this type of error involve something changing a table rowtype that the function uses (that is, ALTER TABLE ADD COLUMN or the like). Or dropping/recreating such a table altogether. I

PG11.2 - wal_level =minimal max_wal_senders = 0

Hello, I have recently upgraded 10 Postgres databases to 11.2, these databases are used for data warehousing / ETL. These are stand alone systems, no replication. They perform a lot of inserts, drop tables and create tables etc... I have been working on tuning the databases, I am seeing the foll

RE: Running a Simple Update Statement Fails, Second Time Suceeds.

Here is function code: -- CREATE OR REPLACE FUNCTION sddf_update.tps_update_1(p_pres_id_in bigint, p_last_audit_update_dt_in timestamp without time zone, OUT p_err_code_out bigint, OUT p_err_mesg_out text, p_expiration_dt_in timestamp without time zone DEFAULT '1600-01-01'::date, p_audit_insert_

Re: Postgres HA issue - Standby server does not start after Master compute host is shut down

On Tue, Sep 3, 2019 at 6:08 PM Nagendra Bandi wrote: > Standby is built from the primary using pg_basebackup. i.e. Initial copy of > the primary database is taken with pg_basebackup command and then restarted > the server. This puzzles me: < 2019-09-01 15:43:56.440 UTC >LOG: trigger file foun

Re: Postgres HA issue - Standby server does not start after Master compute host is shut down

On Tue, 3 Sep 2019 21:31:23 +0530 Nagendra Bandi wrote: > Hi Jehan, > Thanks for your quick response. > Standby is built from the primary using pg_basebackup. i.e. Initial copy of > the primary database is taken with pg_basebackup command pg_basebackup is supposed to make an non-exclusive backup

Re: Slow statement using parallelism after 9.6>11 upgrade

Le 04/09/2019 à 09:04, Arnaud L. a écrit : Le 03/09/2019 à 15:43, Tom Lane a écrit : The planner should be able to do better than that, given up-to-date statistics on the "nodes" column. Tom, I can confirm that with up to date statistics the planner is still lost. I did a REINDEX to rule out a

Re: Bad Estimate for multi tenant database queries

Hello Michael, I digged a bit deeper and found an even simpler query, which can perfectly embody that problem: explain (ANALYZE, FORMAT text) select * from "Reservation"."Reservation" r join "Rates"."TimeSliceDefinition" t on r."TimeSliceDefinitionId" = t."Id" where r."AccountCode" = 'OXHV' and t

Re: Slow statement using parallelism after 9.6>11 upgrade

Le 04/09/2019 à 09:04, Arnaud L. a écrit : Tom, I can confirm that with up to date statistics the planner is still lost. I did a REINDEX to rule out a broken index and the estimate is still in the 100k+ range. Sorry, I meant 1M+ range. EXPLAIN ANALYZE select id from planet_osm_ways WHERE nodes

Re: Slow statement using parallelism after 9.6>11 upgrade

Le 03/09/2019 à 15:43, Tom Lane a écrit : "Arnaud L." writes: We have upgraded our database from 9.6 to 11 (and updated PostGIS from 2.3 to 2.5 as well). ... Have you re-ANALYZEd the database? The problem with this query seems to be the spectacularly awful rowcount estimate here: -> Bi