Re: [HACKERS] Parallel Queries and PostGIS

2016-04-26 Thread Paul Ramsey
On Fri, Apr 22, 2016 at 11:44 AM, Stephen Frost wrote: > Paul, > > * Paul Ramsey (pram...@cleverelephant.ca) wrote: >> On Mon, Mar 28, 2016 at 9:45 AM, Stephen Frost wrote: >> > Would you agree that it'd be helpful to have for making the st_union() >> > work better in parallel? >> >> For our part

Re: [HACKERS] Parallel Queries and PostGIS

2016-04-22 Thread Stephen Frost
Paul, * Paul Ramsey (pram...@cleverelephant.ca) wrote: > On Mon, Mar 28, 2016 at 9:45 AM, Stephen Frost wrote: > > Would you agree that it'd be helpful to have for making the st_union() > > work better in parallel? > > For our particular situation w/ ST_Union, yes, it would be ideal to be > able

Re: [HACKERS] Parallel Queries and PostGIS

2016-04-12 Thread David Rowley
On 1 April 2016 at 17:12, David Rowley wrote: > On 30 March 2016 at 09:14, Robert Haas wrote: >> On Tue, Mar 29, 2016 at 3:48 PM, Paul Ramsey >> wrote: I have no idea why the cost adjustments that you need are different for the scan case and the aggregate case. That does seem problem

Re: [HACKERS] Parallel Queries and PostGIS

2016-03-31 Thread David Rowley
On 30 March 2016 at 09:14, Robert Haas wrote: > On Tue, Mar 29, 2016 at 3:48 PM, Paul Ramsey > wrote: >>> I have no idea why the cost adjustments that you need are different >>> for the scan case and the aggregate case. That does seem problematic, >>> but I just don't know why it's happening. >

Re: [HACKERS] Parallel Queries and PostGIS

2016-03-31 Thread Amit Kapila
On Fri, Apr 1, 2016 at 12:49 AM, Paul Ramsey wrote: > > On Tue, Mar 29, 2016 at 12:51 PM, Paul Ramsey wrote: > > On Tue, Mar 29, 2016 at 12:48 PM, Paul Ramsey wrote: > > > >>> On the join case, I wonder if it's possible that _st_intersects is not > >>> marked parallel-safe? If that's not the pr

Re: [HACKERS] Parallel Queries and PostGIS

2016-03-31 Thread Paul Ramsey
On Tue, Mar 29, 2016 at 12:51 PM, Paul Ramsey wrote: > On Tue, Mar 29, 2016 at 12:48 PM, Paul Ramsey > wrote: > >>> On the join case, I wonder if it's possible that _st_intersects is not >>> marked parallel-safe? If that's not the problem, I don't have a >>> second guess, but the thing to do wo

Re: [HACKERS] Parallel Queries and PostGIS

2016-03-29 Thread Paul Ramsey
On Tue, Mar 29, 2016 at 1:14 PM, Robert Haas wrote: > On Tue, Mar 29, 2016 at 3:48 PM, Paul Ramsey > wrote: >>> I have no idea why the cost adjustments that you need are different >>> for the scan case and the aggregate case. That does seem problematic, >>> but I just don't know why it's happen

Re: [HACKERS] Parallel Queries and PostGIS

2016-03-29 Thread Robert Haas
On Tue, Mar 29, 2016 at 3:48 PM, Paul Ramsey wrote: >> I have no idea why the cost adjustments that you need are different >> for the scan case and the aggregate case. That does seem problematic, >> but I just don't know why it's happening. > > What might be a good way to debug it? Is there a pie

Re: [HACKERS] Parallel Queries and PostGIS

2016-03-29 Thread Paul Ramsey
On Tue, Mar 29, 2016 at 12:48 PM, Paul Ramsey wrote: >> On the join case, I wonder if it's possible that _st_intersects is not >> marked parallel-safe? If that's not the problem, I don't have a >> second guess, but the thing to do would be to figure out whether >> consider_parallel is false for

Re: [HACKERS] Parallel Queries and PostGIS

2016-03-29 Thread Paul Ramsey
> First, I beg to differ with this statement: "Some of the execution > results output are wrong! " The point is that > line has loops=4, so as in any other case where loops>1, you're seeing > the number of rows divided by the number of loops. It is the > *average* number of rows that were pro

Re: [HACKERS] Parallel Queries and PostGIS

2016-03-29 Thread Robert Haas
On Mon, Mar 28, 2016 at 12:18 PM, Paul Ramsey wrote: > I spent some time over the weekend trying out the different modes of > parallel query (seq scan, aggregate, join) in combination with PostGIS > and have written up the results here: > > http://blog.cleverelephant.ca/2016/03/parallel-postgis.ht

Re: [HACKERS] Parallel Queries and PostGIS

2016-03-29 Thread Paul Ramsey
On Mon, Mar 28, 2016 at 9:18 AM, Paul Ramsey wrote: > Parallel join would be a huge win, so some help/pointers on figuring > out why it's not coming into play when our gist operators are in > effect would be helpful. Robert, do you have any pointers on what I should look for to figure out why th

Re: [HACKERS] Parallel Queries and PostGIS

2016-03-28 Thread Paul Ramsey
On Mon, Mar 28, 2016 at 9:45 AM, Stephen Frost wrote: > Paul, > > * Paul Ramsey (pram...@cleverelephant.ca) wrote: >> I spent some time over the weekend trying out the different modes of >> parallel query (seq scan, aggregate, join) in combination with PostGIS >> and have written up the results he

Re: [HACKERS] Parallel Queries and PostGIS

2016-03-28 Thread Stephen Frost
Paul, * Paul Ramsey (pram...@cleverelephant.ca) wrote: > I spent some time over the weekend trying out the different modes of > parallel query (seq scan, aggregate, join) in combination with PostGIS > and have written up the results here: > > http://blog.cleverelephant.ca/2016/03/parallel-postgis

Re: [HACKERS] Parallel queries

2001-02-05 Thread Thomas Lockhart
> How hard would it be to get a back end to hand off parts of a query > tree to other back ends (which it created), and then collate the > results, and take it from there? Obviously, it would only do this > under certain conditions, specifically, if it was compiled in to the > server, and the que