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
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 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
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
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
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
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
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
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
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
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
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 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 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
14 matches
Mail list logo
