On Fri, Dec 11, 2015 at 3:37 PM, Carlo Cabanilla wrote:
> 16 cores
> a default pool size of 650, steady state of 500-600 server
> connections
With so many more connections than resources to serve them, one
thing that can happen is that just by happen-stance enough processes
become busy at one t
On Fri, Dec 11, 2015 at 2:11 PM, Corradini, Carlos
wrote:
> with your and Mr. Kevin explanations, the Java
> program have worked fine and have printed the data obtained from a two
> cursors inside a PostgreSQL Database Stored Function.
>
> Then, I can confirm that this version of DB ( 9.4 ) use t
On 12/11/15 3:55 PM, Will McCormick wrote:
> Basic backup and recovery question. I want to perform complete restore
> and recovery using continuous archive mode.
>
> Lets imagine we have a single table MYTABLE. Here are my high level steps
>
> 1) Add a record A) to MYTABLE
> 2) Take a file syste
On Fri, Dec 11, 2015 at 3:15 PM, John R Pierce wrote:
> 1) Stop PG <- no, instead, execute: select pg_start_backup();
> 2) Make copy of current state including PGDATA w/ pg_xlog <= don't backup
> the WAL archives, they are external to the database server, and are written
> continuously.
> 3) S
Thanks for the reply Kevin.
> > I'm trying to figure out why we had a build up of connections on
> > our streaming replica.
>
> Seriously, from the data provided, about all I can say is "because
> you were opening them faster than you were closing them". You
> don't say how many cores or how muc
1) Stop PG <- no, instead, execute: select pg_start_backup();
2) Make copy of current state including PGDATA w/ pg_xlog <= don't
backup the WAL archives, they are external to the database server, and
are written continuously.
3) Select pg_stop_backup();
4) run along until your problem happe
Basic backup and recovery question. I want to perform complete restore and
recovery using continuous archive mode.
Lets imagine we have a single table MYTABLE. Here are my high level steps
1) Add a record A) to MYTABLE
2) Take a file system backup to be used for recovery. This backup includes
ar
On Thu, Dec 10, 2015 at 5:13 PM, Carlo Cabanilla wrote:
> I'm trying to figure out why we had a build up of connections on
> our streaming replica.
Seriously, from the data provided, about all I can say is "because
you were opening them faster than you were closing them". You
don't say how many
Mr. Adrian, first let me say many thanks for your replies, were very
helpful for me. But, I must to say this other .
I take a copy from the function from the gui tool of pgadmin III called
query sql, the original function name all the parameters, I do not know
why this gui tool change that.
Y
Mr. Adrian, here i transcribe the code of the function
-- Function: dw_bsc.proc_perspectives(character varying, integer,
character varying, character varying, character varying, integer, date)
-- DROP FUNCTION dw_bsc.proc_perspectives(character varying, integer,
character varying, character varyi
Maxim Boguk writes:
> [ planner changes behavior when a VALUES RTE reaches 200 elements ]
The immediate cause of that is that, lacking any real statistics for the
VALUES RTE, eqjoinsel_semi() will fall back to a rather dubious default
estimate if it believes it's looking at a default estimate for
On 12/11/2015 07:10 AM, Corradini, Carlos wrote:
Mr. Adrian, first let me say many thanks for your replies, were very
helpful for me. But, I must to say this other .
I take a copy from the function from the gui tool of pgadmin III called
query sql, the original function name all the paramete
Hi,
I found very weird behaviour on planner side with estimation error of
700.000.000.
Situation (with explain analyze):
EXPLAIN ANALYZE
select * from person2obj
WHERE
p2o_id IN (SELECT p2o_id::bigint FROM (SELECT * FROM (SELECT column1 AS
p2o_id FROM (
VALUES ('2056892'), up to
On 12/11/2015 04:56 AM, Corradini, Carlos wrote:
Mr. Adrian, here i transcribe the code of the function
Notes in line.
-- Function: dw_bsc.proc_perspectives(character varying, integer,
character varying, character varying, character varying, integer, date)
-- DROP FUNCTION dw_bsc.proc_persp
14 matches
Mail list logo
