On Tue, Oct 21, 2014 at 11:50 AM, Tom Lane t...@sss.pgh.pa.us wrote:
Marco Di Cesare marco.dices...@pointclickcare.com writes:
COUNT(DISTINCT foxtrot_india.bravo_romeo)
Ah. That explains why the planner doesn't want to use a hash aggregation
step --- DISTINCT aggregates
2014-10-20 21:59 GMT-02:00 Tom Lane t...@sss.pgh.pa.us:
Marco Di Cesare marco.dices...@pointclickcare.com writes:
We are using a BI tool that generates a query with an unusually large
number of joins. My understanding is that with this many joins Postgres
query planner can't possibly use an
On Mon, Oct 20, 2014 at 3:32 PM, Marco Di Cesare
marco.dices...@pointclickcare.com wrote:
We are using Postgres for the first time after being SQLServer users for a
long time so forgive for being noobs.
We are using a BI tool that generates a query with an unusually large number
of joins.
...@gmail.com]
Sent: Tuesday, October 21, 2014 9:39 AM
To: Marco Di Cesare
Cc: pgsql-performance@postgresql.org
Subject: Re: [PERFORM] Query with large number of joins
On Mon, Oct 20, 2014 at 3:32 PM, Marco Di Cesare
marco.dices...@pointclickcare.com wrote:
We are using Postgres for the first
On 10/21/2014 12:09 PM, Marco Di Cesare wrote:
I did not mean to imply this works any better on SQL Server. We never tried. I
just meant to say this is the first time we are using Postgres so we don't have
much experience with it.
We tried with work_mem set to 1GB (even as high as 3GB) but
Andrew Dunstan and...@dunslane.net writes:
Have you tried a) either turning off geqo or setting geqo_threshold
fairly high b) setting join_collapse_limit fairly high (assuming all the
above join targets are tables and not views, setting it to something
like 25 should do the trick.
You'd
Marco Di Cesare marco.dices...@pointclickcare.com writes:
COUNT(DISTINCT foxtrot_india.bravo_romeo)
Ah. That explains why the planner doesn't want to use a hash aggregation
step --- DISTINCT aggregates aren't supported with those.
regards, tom lane
On 10/21/2014 12:31 PM, Andrew Dunstan wrote:
Please don't top-post on the PostgreSQL lists. See
http://idallen.com/topposting.html
Oops, sorry.
Have you tried a) either turning off geqo or setting geqo_threshold fairly
high b) setting join_collapse_limit fairly high (assuming
all the
Andrew Dunstan and...@dunslane.net writes:
Have you tried a) either turning off geqo or setting geqo_threshold
fairly high b) setting join_collapse_limit fairly high (assuming all
the above join targets are tables and not views, setting it to
something like 25 should do the trick.
Tom
with large number of joins
On 10/21/2014 12:31 PM, Andrew Dunstan wrote:
Please don't top-post on the PostgreSQL lists. See
http://idallen.com/topposting.html
Oops, sorry.
Have you tried a) either turning off geqo or setting geqo_threshold
fairly high b) setting join_collapse_limit fairly high
We are using Postgres for the first time after being SQLServer users for a long
time so forgive for being noobs.
We are using a BI tool that generates a query with an unusually large number of
joins. My understanding is that with this many joins Postgres query planner
can't possibly use an
Marco Di Cesare marco.dices...@pointclickcare.com writes:
We are using a BI tool that generates a query with an unusually large number
of joins. My understanding is that with this many joins Postgres query
planner can't possibly use an exhaustive search so it drops into a heuristics
12 matches
Mail list logo
