Hi,
For a traditional LEFT JOIN, in case the SELECT does not mention a field
from a joined table being unique , the planner removes the join. Eg:
SELECT a, b --,c
FROM table1
LEFT JOIN (select a, c from table2 group by a) joined USING (a)
However this behavior is not the same for LATERAL JOINS
Nicolas Paris writes:
> For a traditional LEFT JOIN, in case the SELECT does not mention a field
> from a joined table being unique , the planner removes the join. Eg:
> SELECT a, b --,c
> FROM table1
> LEFT JOIN (select a, c from table2 group by a) joined USING (a)
> However this behavior is
Why the sql is not executed in parallel mode, does the sql has some problem?
with sql1 as
(select a.*
from snaps a
where a.f_date between to_date('2018-03-05', '-MM-dd') and
to_date('2018-03-11', '-MM-dd')
),
sql2 as
(select '1' as pId, PM_TO as pValue, type_code as typeCode,
On Wed, Sep 19, 2018 at 1:53 PM jimmy wrote:
>
> Why the sql is not executed in parallel mode, does the sql has some problem?
> with sql1 as
Hello Jimmy,
WITH is the problem. From the manual[1]: "The following operations
are always parallel restricted. Scans of common table expressions
Hi,
pg_pub_decrypt() is ~10x slower when the priv/pub keys have been
generated with gnupg version 2.x instead of version 1.x.
What I do is:
- Create keys with gpg
- Export priv/pub keys
- Store keys in binary form in a bytea
- Create 32 byte random data and encrypt it with pg_pub_encrypt()
-
