n future Hash Join might be the best and cheapest way.
Can you try reproducing it with small data or else can you attach your schema
and data for the tables/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
65.81
> rows=580 width=8)
> Filter: ((algorithm)::text = 'SMAT'::text)
> Does anyone have suggestions about how to speed it up?
Could you please once trying Analyzing both tables and then run the query to
check which plan it uses:
Analyze SARS_ACTS;
An
llowed on that relation. Most of admin care about
this point, because
they don't want to stop operations for background garbage collect.
VACUUM FULL is only done in rare cases when the relation size has grown too
bigger than it's actual
Contents.
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
server should start with
Pg_ctl.exe start -D data_dir
Where data_dir is the path where you have created your 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
> -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
on, will this problem remains.
Is there any chance that the block gets corrupted due to hardware problem?
2. missing clog files - how did you find missing clog files, is any
operation got failed 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
ght, then you can try with using DISTINCT operator:
http://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
;dim_id" IS NULL
> Line: 1
>
> [Executed: 2/4/13 11:07:08 PM PST ] [Execution: 0/ms]
>
>
> exception.
>
> Is there anything i am missing.
Why the query is different in Exception?
Can you try with
SELECT
tbl.id,
tbl.day,
tbl.week,
t
om columns in the
database 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,
You can try once with below query:
Select * from (SELECT a.id,b.value FROM table_a a, table_b b WHERE ... 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.
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
ct, then the rows will be
locked during whole transaction
irrespective 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
ese
parameters are USERSET parameters,
so 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
th psql. verify the entry for
same 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
r you call cancel/terminate
Backend 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://
n
> pg_stat_activity).
Can you check 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 (pgs
ormation is part of pg_stat_activity, but don't
know how to get in the version you are using.
If possible for you, get this information. If you are using Linux system the
try ps ax | grep postgres and show the output
> Also, tried to Kill it Firstly by using Cancel Backend and then
&
d(pid) 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
nside some app logic which at the time of dev,
got missed for test then it might reach production stage.
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 Monday, September 24, 2012 8:19 PM Tom Lane wrote:
> Amit Kapila 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.
>
>
> 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 funct
NTO TEST_TABLE VALUES（'jack',25);
Now, 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.
PostgreSQL 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
