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()
>> >
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
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
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
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
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,
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
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
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
>>
> 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
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:
>
>
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
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
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:
>
>
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.html
The TL:DR; is basically
* With some adjustments to
15 matches
Mail list logo