Hi Stefan!
Probably you need to rewrite your query like this (check it first):
with RECURSIVE qq(cont_key, anc_key) as
(
select min(a1.context_key), ancestor_key from virtual_ancestors a1
union select
(SELECT
a1.context_key, ancestor_key
FROM
virtual_ancestors a1 where context_key >
Le 20/03/2014 18:13, Torsten Förtsch a écrit :
On 20/03/14 17:57, Jean-Max Reymond wrote:
I have a very complex view zinfoexp and running the view as:
SELECT * FROM zinfoexp WHERE idmembre in (1,84)
take 2700 ms
So, I try another syntax:
SELECT * FROM zinfoexp WHERE idmembre = 1
union
SELECT
We have a slow performing query that we are trying to improve, and it
appears to be performing a sequential scan at a point where it should be
utilizing an index. Can anyone tell me why postgres is opting to do it this
way?
The original query is as follows:
SELECT DISTINCT
a1.context_key
FROM
On 20/03/14 17:57, Jean-Max Reymond wrote:
> I have a very complex view zinfoexp and running the view as:
> SELECT * FROM zinfoexp WHERE idmembre in (1,84)
> take 2700 ms
>
> So, I try another syntax:
> SELECT * FROM zinfoexp WHERE idmembre = 1
> union
> SELECT * FROM zinfoexp WHERE idmembre =
Stefan Keller writes:
> I'd like to know from the query planner which query plan alternatives
> have been generated and rejected. Is this possible?
No, not really. People have occasionally hacked the planner to print
rejected paths before they're discarded, but there's no convenient way
to do an
Hi,
I'd like to know from the query planner which query plan alternatives
have been generated and rejected. Is this possible?
--Stefan
--
Sent via pgsql-performance mailing list (pgsql-performance@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-pe
I have a very complex view zinfoexp and running the view as:
SELECT * FROM zinfoexp WHERE idmembre in (1,84)
take 2700 ms
So, I try another syntax:
SELECT * FROM zinfoexp WHERE idmembre = 1
union
SELECT * FROM zinfoexp WHERE idmembre = 84
and for me, two calls to my view takes a lot of time (
Le 20/03/2014 15:15, Tom Lane a écrit :
> Hm. The next most likely theory is that it's waiting on network I/O,
> but it's hard to tell that from the outside. Can you attach to the
> stuck backend with gdb and get a stack trace?
> http://wiki.postgresql.org/wiki/Generating_a_stack_trace_of_a_Postg
Franck Routier writes:
> Le 20/03/2014 14:56, Tom Lane a écrit :
>> pg_locks, probably. regards, tom lane
> select * from pg_stat_activity shows 'F'alse in the waiting column for
> the query.
Hm. The next most likely theory is that it's waiting on network I/O,
but it's hard to tell that from th
Le 20/03/2014 14:56, Tom Lane a écrit :
> pg_locks, probably. regards, tom lane
select * from pg_stat_activity shows 'F'alse in the waiting column for
the query.
Can I rely on that or should I be investigating further for subtile
types of locks ?
smime.p7s
Description: Signature cryptographi
Franck Routier writes:
> I am doing a select, that did not finish after some 15 hours... Select
> is as follows:
> select * from sanact where sanact___rfovsnide = 'MYVERSION' order by
> sanactcsu;
> There is an index on sanact___rfovsnide and doing EXPLAIN shows it is used.
> Resulting dataset s
Hi,
I have a table (sanact) with 23.125.525 rows (and a hundred columns).
I am doing a select, that did not finish after some 15 hours... Select
is as follows:
select * from sanact where sanact___rfovsnide = 'MYVERSION' order by
sanactcsu;
There is an index on sanact___rfovsnide and doing EXPLAI
Hello,
New server postgres version is 9.3. I'm not sure if I collected latest
statistics after migration, if you mean if the current_settings or analyze
queries that I posted were collected after migration... yes (notice that there
are analyze query before migration and after migration, maybe I
13 matches
Mail list logo
