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
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
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
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.
>
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
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
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
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
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
> 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
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
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
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
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
> 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
15 matches
Mail list logo