/indexes used in query?
With Regards,
Amit Kapila.
--
Sent via pgsql-general mailing list (pgsql-general@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-general
both tables and then run the query to
check which plan it uses:
Analyze SARS_ACTS;
Analyze SARS_ACTS_RUN;
With Regards,
Amit Kapila.
--
Sent via pgsql-general mailing list (pgsql-general@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-general
.
With Regards,
Amit Kapila.
--
Sent via pgsql-general mailing list (pgsql-general@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-general
database.
With Regards,
Amit Kapila.
--
Sent via pgsql-general mailing list (pgsql-general@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-general
or just an observation?
Do you see any problems in system due to it?
With Regards,
Amit Kapila.
--
Sent via pgsql-general mailing list (pgsql-general@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-general
-Original Message-
From: Merlin Moncure [mailto:mmonc...@gmail.com]
Sent: Friday, February 15, 2013 7:56 PM
To: Amit Kapila
Cc: Ben Chobot; PostgreSQL General
Subject: Re: [GENERAL] bug, bad memory, or bad disk?
On Fri, Feb 15, 2013 at 8:08 AM, Amit Kapila amit.kap...@huawei.com
://www.postgresql.org/docs/9.2/static/sql-select.html#SQL-DISTINCT
With Regards,
Amit Kapila.
--
Sent via pgsql-general mailing list (pgsql-general@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-general
as the
parameters of a set-returning function from which I want to select *.
Can you try with RETURN NEXT syntax. For example, refer below link:
http://www.postgresql.org/docs/9.2/static/plpgsql-control-structures.html#PL
PGSQL-STATEMENTS-RETURNING
With Regards,
Amit Kapila.
--
Sent via pgsql
tbl
left outer join DIM_deviceMakeModel ext6 on
(ext6.DIM_ID=tbl.devicemakemodel)
ORDER BY tbl.id ASC
Also as Pavel has pointed, send this to General mailing list.
With Regards,
Amit Kapila.
--
Sent via pgsql-general mailing list (pgsql-general@postgresql.org)
To make changes
... AND ...
) X where X.value=...;
If this doesn't work can you send the Explain .. output for both queries(the
query you are using and the query I have suggested)
With Regards,
Amit Kapila.
--
Sent via pgsql-general mailing list (pgsql-general@postgresql.org)
To make changes to your subscription:
http
of the fact that they will not be updated.
With Regards,
Amit Kapila.
--
Sent via pgsql-general mailing list (pgsql-general@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-general
On Sunday, January 06, 2013 11:10 AM Amit kapila wrote:
On Sunday, January 06, 2013 7:48 AM Chris Travers wrote:
Is there a reason why we don't do locking this way? (i.e. where on UPDATE
foo, all rows selected from foo during the
update are locked unless the subselect specifically states
no need to change config file and reload or restart.
With Regards,
Amit Kapila.
--
Sent via pgsql-general mailing list (pgsql-general@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-general
in pg_stat_activity. call terminate API for this session. check again if
the new entry has gone from pg_stat_activity?
With Regards,
Amit Kapila.
--
Sent via pgsql-general mailing list (pgsql-general@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-general
API?
FATAL: terminating connection due to administrator command
ERROR: canceling statement due to user request
With Regards,
Amit Kapila.
--
Sent via pgsql-general mailing list (pgsql-general@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-general
. in
pg_stat_activity).
Are you aware whether there is actually such long query running in first 2
sessions.
If you are not interested in first 2 sessions, you can even use OS kill
command.
With Regards,
Amit Kapila.
--
Sent via pgsql-general mailing list (pgsql-general@postgresql.org)
To make changes to your
the server log and see if there is any of below the statements
in the log:
FATAL: terminating connection due to administrator command
ERROR: canceling statement due to user request
With Regards,
Amit Kapila.
--
Sent via pgsql-general mailing list (pgsql-general@postgresql.org)
To make changes
) and then pg_terminate_backend.
With Regards,
Amit Kapila.
--
Sent via pgsql-general mailing list (pgsql-general@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-general
,
Amit Kapila.
--
Sent via pgsql-general mailing list (pgsql-general@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-general
On Monday, September 24, 2012 8:19 PM Tom Lane wrote:
Amit Kapila amit.kap...@huawei.com writes:
Below test results into Loop:
[ AFTER INSERT trigger does another insert into its target table ]
Well, of course. The INSERT results in scheduling another AFTER event.
I understand
, You will see an always loop.
I understand that user can change his code to make it proper.
However shouldn’t PostgreSQL also throws errors in such cases for recursion
level or something related?
With Regards,
Amit Kapila.
On Monday, September 24, 2012 7:44 PM Adrian Klaver
On 09/24/2012 07:03 AM, Amit Kapila wrote:
Below test results into Loop:
1.create test table
CREATE TABLE TEST_TABLE (NAME VARCHAR2, AGE INT);
2.create trigger function
CREATE OR REPLACE FUNCTION TRIG_FUNC () RETURNS TRIGGER
or is it a bug or a new
feature in itself.
In case it is not clear, I will raise a bug.
With Regards,
Amit Kapila
23 matches
Mail list logo