Hi Stefan,
stupid me - Ive missed some
with RECURSIVE qq(cont_key, anc_key) AS
(
SELECT
a1.context_key, ancestor_key
FROM
virtual_ancestors a1
UNION select ( -- here, in the union
SELECT
a1.context_key, a1.ancestor_key
FROM
virtual_ancestors
Hi Ilya-
Thanks so much for taking a stab at optimizing that query. I had to fiddle
a bit with your proposed version in order to get it function. Here's what I
came up with in the end:
with RECURSIVE qq(cont_key, anc_key) AS
> (
> SELECT
> a1.context_key, ancestor_key
> FROM
>
On 21-03-14 00:56, Stefan Amshey wrote:
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 foll
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 >
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
