Re: Foreign table performance issue / PostgreSQK vs. ORACLE

2021-02-03 Thread Sebastian Dressler
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>

Re: Foreign table performance issue / PostgreSQK vs. ORACLE

2021-01-30 Thread Sebastian Dressler
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

Re: CPU Configuration - postgres

2020-06-11 Thread Sebastian Dressler
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

Re: Planner misestimation for JOIN with VARCHAR

2020-06-09 Thread Sebastian Dressler
> 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

Planner misestimation for JOIN with VARCHAR

2020-06-09 Thread Sebastian Dressler
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