use auto_explain to fetch plans and see whether these claims
apply.
Best,
Sebastian
--
[1]: https://gist.github.com/sdressler/9a93d66b7052dc75ec45c0a4bf5c61de
Sebastian Dressler, Solution Architect, Swarm64
+49 30 994 0496 72 | sebast...@swarm64.com<mailto:sebast...@swarm64.com>
Such an extension can potentially fix your
performance issue. However, I have not tried it so far with a setup similar to
yours.
Cheers,
Sebastian
[1]: https://github.com/swarm64/parallel-postgres-fdw-patch
--
Sebastian Dressler, Solution Architect, Swarm64 AS
+49 30 994 0496 72 | sebast...@swarm64.com
esses
Where the first two essentially can limit the amount of cores to be used.
Is that what you were asking for?
Cheers,
Sebastian
--
Sebastian Dressler, Solution Architect
+49 30 994 0496 72 | sebast...@swarm64.com
Swarm64 AS
Parkveien 41 B | 0258 Oslo | Norway
Registered at Brønnøysundr
> On 9. Jun 2020, at 21:30, Michael Lewis wrote:
>
>> On Tue, Jun 9, 2020 at 12:34 PM Sebastian Dressler
>> wrote:
>> - Add an index on top of the whole PK
>> - Add indexes onto other columns trying to help the JOIN
>> - Add additional statistics on two r
hash the PKs
together to an BIGINT and solely use this for the JOIN. However, this would not
work when not all columns of the PK are used for the JOIN.
Thanks,
Sebastian
--
Sebastian Dressler, Solution Architect
+49 30 994 0496 72 | sebast...@swarm64.com
Swarm64 AS
Parkveien 41 B | 0258 O