On Thu, Aug 30, 2018 at 6:55 PM Tom Lane wrote:
> Alexander Korotkov writes:
> > I understand that startup cost is not "time to find the first row".
> > But I think this example highlight not one but two issues.
> > 1) Row count estimates for joins are wrong.
>
> Yup.
>
> > 2) Rows are assumed to
Robert Haas writes:
> Whose mental model? I guess the Tom Lane mind is the canonical one
> for this project, but I'm not sure that it entirely agrees with mine.
Since the fact that we have a notion of startup cost at all is entirely my
fault, I don't feel shy about claiming to have the authorita
On Thu, Aug 30, 2018 at 10:04 AM, Tom Lane wrote:
> Alexander Korotkov writes:
>> But I think there is another issue in sequential scan cost. We have
>> zero startup cost for sequential scan. But why?
>
> Because it's what the mental model of startup cost says it should be.
Whose mental model?
Alexander Korotkov writes:
> I understand that startup cost is not "time to find the first row".
> But I think this example highlight not one but two issues.
> 1) Row count estimates for joins are wrong.
Yup.
> 2) Rows are assumed to be continuous while in reality they are
> discrete.
Where do
On Thu, Aug 30, 2018 at 5:58 PM Tom Lane wrote:
>
> Alexander Korotkov writes:
> > On Thu, Aug 30, 2018 at 5:05 PM Tom Lane wrote:
> >> Because it's what the mental model of startup cost says it should be.
>
> > From this model we make a conclusion that we're starting getting rows
> > from seque
Andrew Gierth writes:
> The model (assuming I understand it rightly) is that what we're actually
> tracking is a startup cost and a per-output-row cost, but for comparison
> purposes we actually store the rows and the computed total, rather than
> just the per-row cost:
> rows
> startup_cost
> to
> "Konstantin" == Konstantin Knizhnik writes:
>> No, startup cost is not the "time to find the first row". It's
>> overhead paid before you even get to start examining rows.
Konstantin> But it seems to me that calculation of cost in LIMIT node
Konstantin> contradicts with this statement:
On Thu, Aug 30, 2018 at 6:08 PM Konstantin Knizhnik
wrote:
> On 30.08.2018 17:58, Tom Lane wrote:
> > Alexander Korotkov writes:
> >> On Thu, Aug 30, 2018 at 5:05 PM Tom Lane wrote:
> >>> Because it's what the mental model of startup cost says it should be.
> >> From this model we make a conclu
On 30.08.2018 17:58, Tom Lane wrote:
Alexander Korotkov writes:
On Thu, Aug 30, 2018 at 5:05 PM Tom Lane wrote:
Because it's what the mental model of startup cost says it should be.
From this model we make a conclusion that we're starting getting rows
from sequential scan sooner than fro
Alexander Korotkov writes:
> On Thu, Aug 30, 2018 at 5:05 PM Tom Lane wrote:
>> Because it's what the mental model of startup cost says it should be.
> From this model we make a conclusion that we're starting getting rows
> from sequential scan sooner than from index scan. And this conclusion
>
On Thu, Aug 30, 2018 at 5:05 PM Tom Lane wrote:
> Alexander Korotkov writes:
> > But I think there is another issue in sequential scan cost. We have
> > zero startup cost for sequential scan. But why?
>
> Because it's what the mental model of startup cost says it should be.
Right. So as I und
Alexander Korotkov writes:
> But I think there is another issue in sequential scan cost. We have
> zero startup cost for sequential scan. But why?
Because it's what the mental model of startup cost says it should be.
Also, I do not think we can change that without a whole lot of unpleasant
side
Hi!
Our customer have a bad plan problem, which could be reduced to the
following example.
create table t1 (id int primary key, k int);
create table t2 (id int);
insert into t1 (select i, i from generate_series(1,100) i);
insert into t2 (select 0 from generate_series(1,100)i);
insert into t2
13 matches
Mail list logo
