[Postgres-xl-general] Different query plans on different coordinators in same cluster

Dennis dennisr at visi.com
Fri Aug 29 10:56:37 PDT 2014


Hi sorry for late feed back.

I am pretty sure the problem with the different query plans is I have make sure to run ANALYZE on all coordinator nodes after making changes to the schema/indexes.  Doing that seems to fix the problem with different plans on different nodes.

As for the hung REMOTE plans, I am suspecting now that is a result of killing a query but that "kill request” is not being pushed out to the other nodes possibly.   Generally, I see this happen when I do ctr-c in the psql shell to cancel a query and then it appears to leave the REMOTE PLAN processes stranded or at least not killed as well.

So I am happy with the solution to the query plan problem but it would be nice if possible to have the stats updated on all nodes when running ANALYZE on one node.

Thanks for checking back.

Dennis

On Aug 29, 2014, at 12:47 PM, Mason Sharp <msharp at translattice.com> wrote:

> 
> 
> 
> On Wed, Aug 27, 2014 at 9:46 AM, Dennis <dennisr at visi.com> wrote:
> Yep tried those things.  Actually I have the same issue on a vanilla postgresql install with the same data regarding the query plans.
> 
> What I am actually most concerned with now is that after running vacuum analyze against t_week_f on coordinator1 ALL queries are now degraded not just those involving t_week_f.  The problem now seems to be (disregarding the slower query plan) that the REMOTE PLAN threads on coordinator1 are using 100% cpu and all queries timings have degraded to more than 10 to 20 times slower in general.
> 
> It looks like the REMOTE PLAN thread is thrashing and not completing correctly possibly.
> 
> 
> So, if you set this in your session:
> 
>  set enable_bitmapscan=off
> 
> You still get a slow plan, not a fast one? A different slow plan? What does it look like?
> 
> Thanks,
> 
> Mason
> 

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.postgres-xl.org/pipermail/postgres-xl-general-postgres-xl.org/attachments/20140829/455a2008/attachment.htm>


More information about the postgres-xl-general mailing list