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
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 functio
> 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
Title: Parallel queries
All,
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
17 matches
Mail list logo
