On Sat, Dec 5, 2015 at 9:11 PM, Robert Haas wrote:
> here. For example, in the case of nodeSeqscan.c, almost two-thirds of
> the new lines of code are to add three additional methods that aren't
> called in parallel aware mode, and about half of the rest are due to a
> SeqScanState now having one
On Sat, Dec 5, 2015 at 2:29 PM, Tom Lane wrote:
> Meh. Size of first patch is a pretty bad guide to whether a particular
> structural decision is going to be a good idea in the long run. Do you
> need some examples of patches we've rejected because they were done in a
> way that minimized the si
Robert Haas writes:
> On Sat, Dec 5, 2015 at 12:35 PM, Tom Lane wrote:
>> Amit Kapila writes:
>>> To add to whatever has been said above, intention of adding that flag
>>> was also to avoid adding new nodes for parallelism. Basically modify
>>> the existing nodes (like SeqScan) to take care of
On Sat, Dec 5, 2015 at 5:35 PM, Tom Lane wrote:
> The planner does not
> normally[1] use the same path type to represent two fundamentally different
> execution plans with enormously different cost estimates
Eh, this is a typical object modelling dilemma. There are lots of
different path types a
On Sat, Dec 5, 2015 at 12:35 PM, Tom Lane wrote:
> Amit Kapila writes:
>> To add to whatever has been said above, intention of adding that flag
>> was also to avoid adding new nodes for parallelism. Basically modify
>> the existing nodes (like SeqScan) to take care of whatever is needed
>> for p
Amit Kapila writes:
> To add to whatever has been said above, intention of adding that flag
> was also to avoid adding new nodes for parallelism. Basically modify
> the existing nodes (like SeqScan) to take care of whatever is needed
> for parallel execution.
TBH, I would say that that's a damn-
On Fri, Dec 4, 2015 at 4:00 PM, Robert Haas wrote:
> If it's really true that the extra byte I added there has doubled
> planner memory use, then that's definitely cause for concern.
> However, I am skeptical that's really what has happened here. Not
> every path has crossed a power-of-two thresh
On Sat, Dec 5, 2015 at 2:30 AM, Robert Haas wrote:
>
> On Fri, Dec 4, 2015 at 12:50 PM, Tom Lane wrote:
> > So over in my private branch where I've been fooling around with upper
> > planner pathification, I've been sweating bullets to avoid enlarging the
> > size of struct Path, because I was aw
On Fri, Dec 4, 2015 at 6:14 PM, Peter Geoghegan wrote:
> As frustrated as I've sometimes been with those discussions, I do
> recognize that there has to be a middle ground, and that the emphasis
> on distributed costs has as much to do with fairness for every
> contributor as anything else. I woul
On 12/4/15 5:14 PM, Peter Geoghegan wrote:
On Fri, Dec 4, 2015 at 2:44 PM, Jim Nasby wrote:
>I suspect Cachegrind[1] would answer a lot of these questions (though I've
>never actually used it). I can't get postgres to run under valgrind on my
>laptop, but maybe someone that's been successful at
On Fri, Dec 4, 2015 at 2:44 PM, Jim Nasby wrote:
> I suspect Cachegrind[1] would answer a lot of these questions (though I've
> never actually used it). I can't get postgres to run under valgrind on my
> laptop, but maybe someone that's been successful at valgrind can try
> cachegrind (It's just a
On 12/4/15 11:50 AM, Tom Lane wrote:
which means Robert has already blown the planner's space consumption out
by close to a factor of 2, and I should stop worrying. Or else he should
start worrying. Do we really need this field? Did anyone pay any
attention to what happened to planner space co
On Fri, Dec 4, 2015 at 12:50 PM, Tom Lane wrote:
> So over in my private branch where I've been fooling around with upper
> planner pathification, I've been sweating bullets to avoid enlarging the
> size of struct Path, because I was aware that common path types like
> IndexPath and AppendPath wer
Andres Freund writes:
> On 2015-12-04 12:50:09 -0500, Tom Lane wrote:
>> which means Robert has already blown the planner's space consumption out
>> by close to a factor of 2, and I should stop worrying.
> FWIW, for me it's still <= 64 bytes:
No, it's not bare Path I'm worried about, it's IndexP
On 2015-12-04 12:50:09 -0500, Tom Lane wrote:
> So over in my private branch where I've been fooling around with upper
> planner pathification, I've been sweating bullets to avoid enlarging the
> size of struct Path, because I was aware that common path types like
> IndexPath and AppendPath were al
So over in my private branch where I've been fooling around with upper
planner pathification, I've been sweating bullets to avoid enlarging the
size of struct Path, because I was aware that common path types like
IndexPath and AppendPath were already a power-of-2 size (at least on
64-bit machines),
16 matches
Mail list logo
