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
(CTEs)
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,
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 no
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()
- \tim
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
