Hi Team,
While restoring the database using psql getting below error any idea about
this?
psql:AICH01PR.sql:641367264: ERROR: connection for foreign table
"mf_adm_spotservicefiles" cannot be established
DETAIL: ORA-12170: TNS:Connect timeout occurred
--
Thanks,
Prakash.R
> "Wells" == Wells Oliver writes:
Wells> Hi guys, hoping you can help clarify what the 'hierarchy' of
Wells> casts might be in function arguments.
In terms of which casts will be selected in some given context, there
isn't exactly a "hierarchy", but some types are designated as
"preferred"
Ron writes:
> On 7/1/19 2:43 PM, Adrian Klaver wrote:
>> Have you gone through the logs looking for errors/warnings about the stats
>> collector?
> Yes, but there's nothing.
One theory as to what broke is that somebody messed with your system's
packet filtering (firewall) rules, and now the ker
On 7/1/19 5:20 PM, Adrian Klaver wrote:
On 7/1/19 1:38 PM, Ron wrote:
On 7/1/19 2:43 PM, Adrian Klaver wrote:
On 7/1/19 12:30 PM, Ron wrote:
On 7/1/19 1:48 PM, Tom Lane wrote:
Ron writes:
Statistics views like pg_stat_*_tables, pg_stat_*_indexes,
pg_statio_*_tables and pg_statio_*_indexes a
On 7/1/19 1:38 PM, Ron wrote:
On 7/1/19 2:43 PM, Adrian Klaver wrote:
On 7/1/19 12:30 PM, Ron wrote:
On 7/1/19 1:48 PM, Tom Lane wrote:
Ron writes:
Statistics views like pg_stat_*_tables, pg_stat_*_indexes,
pg_statio_*_tables and pg_statio_*_indexes aren't being updated
anymore.
Specifical
On 7/1/19 2:43 PM, Adrian Klaver wrote:
On 7/1/19 12:30 PM, Ron wrote:
On 7/1/19 1:48 PM, Tom Lane wrote:
Ron writes:
Statistics views like pg_stat_*_tables, pg_stat_*_indexes,
pg_statio_*_tables and pg_statio_*_indexes aren't being updated anymore.
Specifically, all counter fields are 0, and
On 7/1/19 1:18 PM, Wells Oliver wrote:
What is it you're showing me exactly? The valid numeric types accepted
(and cast) by both real and numerics?
That there is builtin casting for a source of either float4 or numeric
to the types listed respectively and that numeric offers more choices.
Mig
What is it you're showing me exactly? The valid numeric types accepted (and
cast) by both real and numerics?
On Mon, Jul 1, 2019 at 1:15 PM Adrian Klaver
wrote:
> On 7/1/19 12:18 PM, Wells Oliver wrote:
> > Hi guys, hoping you can help clarify what the 'hierarchy' of casts might
> > be in functi
On 7/1/19 12:18 PM, Wells Oliver wrote:
Hi guys, hoping you can help clarify what the 'hierarchy' of casts might
be in function arguments.
Meaning I have the following two functions
stats.foo1 (a bigint, b bigint) returns a/b::numeric
stats.foo1 (a real, b real) returns a/b::numeric
It's ess
On 7/1/19 12:30 PM, Ron wrote:
On 7/1/19 1:48 PM, Tom Lane wrote:
Ron writes:
Statistics views like pg_stat_*_tables, pg_stat_*_indexes,
pg_statio_*_tables and pg_statio_*_indexes aren't being updated anymore.
Specifically, all counter fields are 0, and date fields are blank.
Does anything sh
On 7/1/19 1:48 PM, Adrian Klaver wrote:
On 7/1/19 11:24 AM, Ron wrote:
On 7/1/19 1:07 PM, Adrian Klaver wrote:
On 7/1/19 10:27 AM, Ron wrote:
Hi.
v9.6.9
Statistics views like pg_stat_*_tables, pg_stat_*_indexes,
pg_statio_*_tables and pg_statio_*_indexes aren't being updated
anymore. Speci
On 7/1/19 1:48 PM, Tom Lane wrote:
Ron writes:
Statistics views like pg_stat_*_tables, pg_stat_*_indexes,
pg_statio_*_tables and pg_statio_*_indexes aren't being updated anymore.
Specifically, all counter fields are 0, and date fields are blank.
Does anything show up in the postmaster log when
Hi guys, hoping you can help clarify what the 'hierarchy' of casts might be
in function arguments.
Meaning I have the following two functions
stats.foo1 (a bigint, b bigint) returns a/b::numeric
stats.foo1 (a real, b real) returns a/b::numeric
It's essentially the same function, but I thought I
On 7/1/19 11:24 AM, Ron wrote:
On 7/1/19 1:07 PM, Adrian Klaver wrote:
On 7/1/19 10:27 AM, Ron wrote:
Hi.
v9.6.9
Statistics views like pg_stat_*_tables, pg_stat_*_indexes,
pg_statio_*_tables and pg_statio_*_indexes aren't being updated
anymore. Specifically, all counter fields are 0, and da
Ron writes:
> Hi.
>
> v9.6.9
>
> Statistics views like pg_stat_*_tables, pg_stat_*_indexes,
> pg_statio_*_tables and pg_statio_*_indexes aren't being updated
> anymore. Specifically, all counter fields are 0, and date fields are
> blank.
Perhaps your stats collector is dead, blocked or dropping
Ron writes:
> Statistics views like pg_stat_*_tables, pg_stat_*_indexes,
> pg_statio_*_tables and pg_statio_*_indexes aren't being updated anymore.
> Specifically, all counter fields are 0, and date fields are blank.
Does anything show up in the postmaster log when you try to query
one of those
On 7/1/19 1:07 PM, Adrian Klaver wrote:
On 7/1/19 10:27 AM, Ron wrote:
Hi.
v9.6.9
Statistics views like pg_stat_*_tables, pg_stat_*_indexes,
pg_statio_*_tables and pg_statio_*_indexes aren't being updated anymore.
Specifically, all counter fields are 0, and date fields are blank.
The first
On 7/1/19 10:27 AM, Ron wrote:
Hi.
v9.6.9
Statistics views like pg_stat_*_tables, pg_stat_*_indexes,
pg_statio_*_tables and pg_statio_*_indexes aren't being updated anymore.
Specifically, all counter fields are 0, and date fields are blank.
The first thing I checked was postgresql.conf (but
Hi.
v9.6.9
Statistics views like pg_stat_*_tables, pg_stat_*_indexes,
pg_statio_*_tables and pg_statio_*_indexes aren't being updated anymore.
Specifically, all counter fields are 0, and date fields are blank.
The first thing I checked was postgresql.conf (but it hasn't been modified
since
Dirk Mika writes:
> I know I can join using the pk, but in oracle using the rowid is faster so I
> wanted to know, if this is possible in PostgreSQL as well.
Existing Postgres releases are not very bright about joins on CTID ---
basically merge join is the only plan type you can get for that.
v1
Hi
Thinking about it, it _has_ to call any BEFORE trigger function
as that might change values of the row to be inserted that
could possibly change the outcome of the test.
Yeah, that was my thought, too. Unfortunately, the affected trigger changes two
columns, so I can't change it t
> As you can see the trigger function is called for the row I try to
> insert, but you can also see that there's no tuple inserted but one
> conflicting.
Ah, right.
Thinking about it, it _has_ to call any BEFORE trigger function
as that might change values of the row to be inserted that
could
Hello Dirk,
pls don't top post, that's the rule here
On 1/7/19 2:40 μ.μ., Dirk Mika wrote:
I've tried it with the following trigger:
CREATE TRIGGER tr_tl_test1
BEFORE INSERT
ON public.test_large
FOR EACH ROW
EXECUTE PROCEDURE tf_tr_tl_test1 ()
The trigger function does nothing spe
I've tried it with the following trigger:
CREATE TRIGGER tr_tl_test1
BEFORE INSERT
ON public.test_large
FOR EACH ROW
EXECUTE PROCEDURE tf_tr_tl_test1 ()
The trigger function does nothing special:
CREATE OR REPLACE FUNCTION public.tf_tr_tl_test1 ()
RETURNS trigger
LANGUAGE 'plpgsql
Dirk Mika schrieb am 01.07.2019 um 13:18:
> The problem with the INSERT ON CONFLICT is that an insert is tried here
> first, which may fire triggers.
>
> In my case there is a fairly expensive INSERT Trigger ON EACH ROW, which I
> would like to avoid.
The insert trigger will only be fired if an
Dirk Mika schrieb am 01.07.2019 um 12:02:
> I know I can join using the pk, but in oracle using the rowid is
> faster so I wanted to know, if this is possible in PostgreSQL as
> well.
Well, in Postgres ctid is not necessarily faster.
I know I can join using the pk, but in oracle using the rowid is faster so I
wanted to know, if this is possible in PostgreSQL as well.
Dirk
--
Dirk Mika
Software Developer
mika:timing GmbH
Strundepark - Kürtener Str. 11b
51465 Bergisch Gladbach
Germany
fon +49 2202 2401-1197
dirk.m...@mikati
Hello Hans,
Thanks for your reply. Yes, we are facing performance issue.
Current output of query is:
postgres=# SELECT pg_stat_database.datname,
postgres-#pg_stat_database.blks_read,
postgres-#pg_stat_database.blks_hit,
postgres-#round((pg_stat_database.blks_hit::double p
> I come from the Oracle world and am trying to convert some queries to
> PostgreSQL syntax. One of these queries is a MERGE statement, which I
> converted into an UPDATE SET FROM WHERE construct. In the original
> query I use the pseudo column ROWID to match a source row with a
> target row.
>
>
On 28/6/19 10:11 μ.μ., Glenn Schultz wrote:
Hi All,
I have a large table partioned by month. I would like to run a query - which
adds derived data to the current data and inserts the data into a new table.
The new table is the target for users.
How can I iterate over the partition tables to
30 matches
Mail list logo
