Joshua White writes:
> On Thu, 20 Dec 2018 at 14:35, Pavel Stehule wrote:
>> čt 20. 12. 2018 v 2:41 odesílatel Ron napsal:
>>> So it's best to kill connections that have been idle for a while?
>> sure - one hour idle connection is too old.
> I'd also assess closing the connection from the clie
On Thu, 20 Dec 2018 at 14:35, Pavel Stehule wrote:
> čt 20. 12. 2018 v 2:41 odesílatel Ron napsal:
>
>> On 12/19/18 7:27 PM, Michael Paquier wrote:
>> [snip]
>> > Each backend stores its own copy of the relation cache, so if you have
>> > idle connections which have been used for other work in t
čt 20. 12. 2018 v 2:41 odesílatel Ron napsal:
> On 12/19/18 7:27 PM, Michael Paquier wrote:
> [snip]
> > Each backend stores its own copy of the relation cache, so if you have
> > idle connections which have been used for other work in the past then
> > the memory of those caches is still around.
On 12/19/18 7:27 PM, Michael Paquier wrote:
[snip]
Each backend stores its own copy of the relation cache, so if you have
idle connections which have been used for other work in the past then
the memory of those caches is still around. Idle connections also have
a CPU cost in Postgres when build
On Thu, Dec 20, 2018 at 11:32:22AM +1100, Joshua White wrote:
>> In my application, the idle sessions are consuming cpu and ram. refer the
>> ps command output.
>>
>
> If you connect to the database, does select * from pg_stat_activity() show
> a lot of idle connections?
Each backend stores its o
>
> In my application, the idle sessions are consuming cpu and ram. refer the
> ps command output.
>
If you connect to the database, does select * from pg_stat_activity() show
a lot of idle connections?
Thank you Pavel, Adrian! That makes a lot of sense. I wasn't aware that in
Oracle you can overload a procedure by its OUT parameters. I had thought in
Postgres procedure overloading would definitely be the same as function
overloading. Looks like the door is still open.
Regards,
Anton
On Sun, Dec
On Tue, Dec 18, 2018 at 5:51 AM Adrian Klaver
wrote:
> On 12/17/18 11:14 PM, Bret Stern wrote:
> > My statement below updates the pricing no problem, but I want it to be
> > formatted with 2 dec points eg (43.23).
> >
> > Started playing with to_numeric but can't figure it out. Lots of
> > exampl
PG_STAT_SQL_PLANS is an extension mixing
pg_stat_statements and auto_explain with a planid.
It is implementing many Oracle like features:
- queryid is based on normalized sql text (no jumbling),
- stored query text isn't normalized,
- a text normalization SQL function is provided,
- sql not finish
On Wed, Dec 19, 2018 at 1:38 PM Михаил Яремчук
wrote:
> When I insert this data in the column with type xml, I get an error "SSL
> SYSCALL error: EOF detected" and the gap of all current connections. When
> I insert a simpler xml, but larger everything is ok.
> version: PostgreSQL 9.6.11 on x86_6
On 12/19/2018 02:12 AM, Condor wrote:
On 18-12-2018 15:51, Adrian Klaver wrote:
[snip]
In addition to what Pavel posted:
select round(43.2335, 2);
round
---
43.23
Beware with round and numeric
select round(43.2375, 2);
round
---
43.24
select 43.2375::numeric(17, 2);
numeri
Le 19/12/2018 à 11:41, Mike Martin a écrit :
cast(nullif(d.joineddate,NULL) as timestamp) != cast(nullif(s.joineddate,'') as timestamp)
Try with
d.joineddate IS DISTINCT FROM s.joineddate
https://www.postgresql.org/docs/current/functions-comparison.html
Cheers
--
Arnaud
I have a situation where I need to update dates in a primary table from
regular imports of data, eg: this is the base select query
select d.row_id,
fname||lname,'joineddate',d.joineddate,'joineddate',s.joineddate,0 as bool1
from import s join members d on d.contact_id=s.contact_id where
cast(nul
On 18-12-2018 15:51, Adrian Klaver wrote:
On 12/17/18 11:14 PM, Bret Stern wrote:
My statement below updates the pricing no problem, but I want it to be
formatted with 2 dec points eg (43.23).
Started playing with to_numeric but can't figure it out. Lots of
examples with to_char in the
manual
14 matches
Mail list logo
