Robert Haas writes:
> ... In an ideal world, I'd like the amount of effort we spend
> planning to be somehow tied to the savings we can expect to get, and
> deploy optimizations like this only in cases where we have a
> reasonable expectation of that effort being repaid.
BTW, so far as that goes:
On Thu, Jan 26, 2012 at 2:27 PM, Tom Lane wrote:
> Robert Haas writes:
Is there a guard in here against joining a parameterized path to an
intermediate relation when no SJ is involved? In other words, if
we're joining a parameterized path on A to a path on B, then either
the
Robert Haas writes:
>>> Is there a guard in here against joining a parameterized path to an
>>> intermediate relation when no SJ is involved? In other words, if
>>> we're joining a parameterized path on A to a path on B, then either
>>> the join to B should satisfy at least part of the parameteri
On Thu, Jan 26, 2012 at 11:54 AM, Robert Haas wrote:
> AFAICS, such queries aren't going to benefit from this optimization,
> so ideally we'd like them to not have to pay little or nothing for it.
There are a few too many negations in that sentence.
Let me try again:
AFAICS, such queries aren't
On Thu, Jan 26, 2012 at 11:04 AM, Tom Lane wrote:
> Robert Haas writes:
>> Is there a guard in here against joining a parameterized path to an
>> intermediate relation when no SJ is involved? In other words, if
>> we're joining a parameterized path on A to a path on B, then either
>> the join to
Robert Haas writes:
> Is there a guard in here against joining a parameterized path to an
> intermediate relation when no SJ is involved? In other words, if
> we're joining a parameterized path on A to a path on B, then either
> the join to B should satisfy at least part of the parameterization
>
On Wed, Jan 25, 2012 at 11:24 AM, Tom Lane wrote:
> I wrote:
>> Attached is a WIP patch for parameterized paths, along the
>> lines we have discussed before: ...
>
> I've made considerable progress on the TODO items I listed: indxpath.c
> has been ripped apart and restructured, and I have it consi
>> To be clear, I'd love to have this feature. But if there is a choice
>> between reducing planning time significantly for everyone and NOT
>> getting this feature, and increasing planning time significantly for
>> everyone and getting this feature, I think we will make more people
>> happy by do
On Wed, Jan 25, 2012 at 1:24 PM, Tom Lane wrote:
> Also, you're assuming that the changes have no upside whatsoever, which
> I fondly hope is not the case. Large join problems tend not to execute
> instantaneously --- so nobody is going to complain if the planner takes
> awhile longer but the res
On Jan 25, 2012, at 12:19 PM, Tom Lane wrote:
>> Why not create a branch? IIRC the build farm can be configured to run
>> branches.
>
> I already know what the patch does against the regression tests.
> Buildfarm testing is not of interest here. What would be of help is,
> say, Kevin volunteeri
"David E. Wheeler" writes:
> On Jan 25, 2012, at 10:24 AM, Tom Lane wrote:
>> Anyway, I'd be willing to hold off committing if someone were to
>> volunteer to test an unintegrated copy of the patch against some
>> moderately complicated application. But it's a sufficiently large
>> patch that I d
On Jan 25, 2012, at 10:24 AM, Tom Lane wrote:
> Anyway, I'd be willing to hold off committing if someone were to
> volunteer to test an unintegrated copy of the patch against some
> moderately complicated application. But it's a sufficiently large
> patch that I don't really care to sit on it and
Robert Haas writes:
> I have to admit that I have a bad feeling about this. It strikes me
> that there is no way we're not going to get complaints about a 35%
> slowdown on planning a large join problem.
I have to admit that I'm worried about that too. However, I hope to
continue whittling away
On Wed, Jan 25, 2012 at 11:24 AM, Tom Lane wrote:
> After that I started doing some performance testing, and the initial
> news was bad: the planner was about 3x slower than 9.1 on a moderately
> large join problem. I've spent the past several days hacking away at
> that, and have got it down to
On 17/01/12 18:06, Tom Lane wrote:
Anyway, I'm hoping to keep hacking at this for a couple more days before
the CF gets into full swing, and hopefully arrive at something committable
for 9.2. I'd really like to get this fixed in this cycle, since it's
been a problem for several releases now.
Co
On 01/17/2012 12:06 AM, Tom Lane wrote:
Well, since I see other committers sending in patches the day after the
nominal commitfest deadline, I don't feel too bad about being a bit late
as well.
To clarify the fairness standard here: submitting a patch before the
CommitFest deadline, then addi
Tom Lane writes:
> Anyway, I'm hoping to keep hacking at this for a couple more days before
> the CF gets into full swing, and hopefully arrive at something committable
> for 9.2. I'd really like to get this fixed in this cycle, since it's
> been a problem for several releases now.
>
> Comments?
17 matches
Mail list logo
