Thank you Dave. I've opened an SR with GP and see if they have any good
suggestion on changing the plan.
Thanks,
Suya
From: David Rowley [dgrowle...@gmail.com]
Sent: Tuesday, October 28, 2014 6:06 PM
To: Huang, Suya
Cc: pgsql-performance@postgresql.org
Subject: Re
On 28.10.2014 22:15, Jeff Chen wrote:
> Hi friends!
>
> I'd love to get a sanity check on whether a fat select query I'm doing
> makes sense given the infrastructure that we have.
>
> We have 3 big tables that we typically join together for certain
> queries: a ~40 million row photos table, a ~20
On 28.10.2014 21:55, jmcdonagh wrote:
> Hi, we have a nightly job that restores current production data to
> the development databases in a 'warm spare' database so that if the
> developers need fresh data, it's ready during the day. When we moved
> from 9.0 to 9.2 suddenly the restores began to ta
Hi friends!
I'd love to get a sanity check on whether a fat select query I'm doing
makes sense given the infrastructure that we have.
We have 3 big tables that we typically join together for certain queries: a
~40 million row photos table, a ~20 million row users table, and a ~50
million row phot
Hi, we have a nightly job that restores current production data to the
development databases in a 'warm spare' database so that if the developers
need fresh data, it's ready during the day. When we moved from 9.0 to 9.2
suddenly the restores began to take from a few hours to more like 15 hours
or s
On Tue, Oct 28, 2014 at 7:26 PM, Huang, Suya
wrote:
> Hi,
>
>
>
> This is the Greenplum database 4.3.1.0.
>
>
Likely this is the wrong place to ask for help. The plan output that you've
pasted below looks very different to PostgreSQL's EXPLAIN output.