Rhhh Lin writes:
> So I decided to intervene and terminate some active sessions (Which were
> active and not waiting) which were all querying this table with a similar
> query, by using pg_backend_terminate(pid). Some of these sessions were in an
> active state for a few days executing this que
That helps, thanks Peter.
Regards,
Ruan
From: pgsql-general-ow...@postgresql.org
on behalf of Peter J. Holzer
Sent: 03 November 2017 08:49
To: pgsql-general@postgresql.org
Subject: Re: [GENERAL] EXPLAIN command just hangs...
On 2017-11-02 20:51:23 +
art the server, implement a vacuum
execution and see where I am at then.
Regards,
Ruan
From: Justin Pryzby
Sent: 03 November 2017 21:33
To: Rhhh Lin
Cc: Tom Lane; pgsql-general@postgresql.org
Subject: Re: [GENERAL] EXPLAIN command just hangs...
On Fri, Nov 03,
On Fri, Nov 03, 2017 at 09:12:02PM +, Rhhh Lin wrote:
> I checked for dead tuples against that particular table initially as I have
> seen performance problems before in a related 'busy' environment which needed
> its frequency of vacuuming to be increased. So I have a query to check for
> t
y repercussions...
Regards,
Ruan
From: Justin Pryzby
Sent: 02 November 2017 21:49
To: Rhhh Lin
Cc: pgsql-general@postgresql.org
Subject: Re: [GENERAL] EXPLAIN command just hangs...
On Thu, Nov 02, 2017 at 09:13:05PM +, Rhhh Lin wrote:
> Yes, it may be an issue with the index, but I&
ot;timestamp", but right now I cannot
check and verify because it just hangs...
Regard,
Ruan
From: Tom Lane
Sent: 02 November 2017 21:40
To: Rhhh Lin
Cc: Justin Pryzby; pgsql-general@postgresql.org
Subject: Re: [GENERAL] EXPLAIN command just hangs.
On 2017-11-02 20:51:23 +, Rhhh Lin wrote:
[...]
> where timestamp BETWEEN 150667656 AND 150875022
[...]
> *Also, as a sidenote - can someone please expand on why one (I was not
> involved
> in the creation of this DB/schema definition) would choose to have the
> definition of the time
On Thu, Nov 02, 2017 at 09:13:05PM +, Rhhh Lin wrote:
> Yes, it may be an issue with the index, but I'd like to have some evidence
> towards that before dropping and recreating (It does not appear that bloat is
> a problem here or dead tuples either).
Why do you say those aren't an issue? Jus
Rhhh Lin writes:
> The EXPLAIN statement is currently 'f' for waiting and 'active' via
> pg_stat_activity, so it is doing something. The ps command does not show me
> anything more verbose.
ps would confirm for sure whether it was eating CPU time, whereas I do not
particularly trust pg_stat_ac
: Justin Pryzby
Sent: 02 November 2017 21:02
To: Rhhh Lin
Cc: pgsql-general@postgresql.org
Subject: Re: [GENERAL] EXPLAIN command just hangs...
On Thu, Nov 02, 2017 at 08:51:23PM +, Rhhh Lin wrote:
> However, this query will run for days without completing. I suspect it has to
> do w
On Thu, Nov 02, 2017 at 08:51:23PM +, Rhhh Lin wrote:
> However, this query will run for days without completing. I suspect it has to
> do with the timestamp predicate and lack of using an appropriate index access
> path. This is what I need to verify/establish.
Perhaps the timestamp index i
Hi all,
version = Postgres 9.3.10
I have a table with approx. 5 million rows. It is defined something like the
below.
col: type:
timestamp bigint
measurement_id integer
value numeric(24,5)
minval numeric(24,5)
maxval numeric(24,5)
There are two BTree indexes in place on the PK ("timestamp", "me
12 matches
Mail list logo
