On Sun, Jan 8, 2023 at 7:08 PM Tom Lane wrote:
> Alexander Korotkov writes:
> > I'm going to push this and backpatch to all supported versions if no
> > objections.
>
> Push yes, but I'd counsel against back-patching. People don't
> generally like unexpected plan changes in stable versions,
Alexander Korotkov writes:
> I'm going to push this and backpatch to all supported versions if no
> objections.
Push yes, but I'd counsel against back-patching. People don't
generally like unexpected plan changes in stable versions, and
that's what a costing change could produce. There's no
On Tue, Dec 6, 2022 at 1:22 PM Ronan Dunklau wrote:
> Le vendredi 2 décembre 2022, 13:58:27 CET Ronan Dunklau a écrit :
> > Le vendredi 2 décembre 2022, 12:33:33 CET Alexander Korotkov a écrit :
> > > Hi, Ronan!
> > > Thank you for your patch. Couple of quick questions.
> > > 1) What magic
Le vendredi 2 décembre 2022, 13:58:27 CET Ronan Dunklau a écrit :
> Le vendredi 2 décembre 2022, 12:33:33 CET Alexander Korotkov a écrit :
> > Hi, Ronan!
> > Thank you for your patch. Couple of quick questions.
> > 1) What magic number 50.0 stands for? I think we at least should make
> > it a
Le vendredi 2 décembre 2022, 12:33:33 CET Alexander Korotkov a écrit :
> Hi, Ronan!
> Thank you for your patch. Couple of quick questions.
> 1) What magic number 50.0 stands for? I think we at least should make
> it a macro.
This is what is used in other tree-descending estimation functions,
Hi, Ronan!
On Fri, Dec 2, 2022 at 1:19 PM Ronan Dunklau wrote:
> Sorry for the delay, but here is an updated patch which changes the costing in
> the following way:
>
> - add a descent cost similar to the btree one is charged for the initial
> entry-tree
> - additionally, a charge is applied per
Le mardi 25 octobre 2022, 16:18:57 CET Tom Lane a écrit :
> Alexander Korotkov writes:
> > I think Tom's point was that it's wrong to add a separate entry-tree CPU
> > cost estimation to another estimation, which tries (very inadequately) to
> > estimate the whole scan cost. Instead, I propose
Alexander Korotkov writes:
> I think Tom's point was that it's wrong to add a separate entry-tree CPU
> cost estimation to another estimation, which tries (very inadequately) to
> estimate the whole scan cost. Instead, I propose writing better estimations
> for both entry-tree CPU cost and
Hi, Ronan!
On Wed, Oct 12, 2022 at 10:15 AM Ronan Dunklau
wrote:
> > > You're right, I was too eager to try to raise the CPU cost
proportionnally
> to
> > > the number of array scans (scalararrayop). I'd really like to
understand
> where
> > > this equation comes from though...
> >
> > So,
> > You're right, I was too eager to try to raise the CPU cost proportionnally
to
> > the number of array scans (scalararrayop). I'd really like to understand
where
> > this equation comes from though...
>
> So, what's the latest update here?
Thanks Michael for reviving this thread.
Before
On Mon, Sep 19, 2022 at 09:15:25AM +0200, Ronan Dunklau wrote:
> You're right, I was too eager to try to raise the CPU cost proportionnally to
> the number of array scans (scalararrayop). I'd really like to understand
> where
> this equation comes from though...
So, what's the latest update
Le vendredi 16 septembre 2022, 22:04:59 CEST Tom Lane a écrit :
> Ronan Dunklau writes:
> > The attached does that and is much simpler. I only took into account
> > entryPagesFetched, not sure if we should also charge something for data
pages.
>
> I think this is wrong, because there is already
Ronan Dunklau writes:
> The attached does that and is much simpler. I only took into account
> entryPagesFetched, not sure if we should also charge something for data pages.
I think this is wrong, because there is already a CPU charge based on
the number of tuples visited, down at the very end
Le lundi 12 septembre 2022, 16:41:16 CEST Ronan Dunklau a écrit :
> But I realised that another approach might be better suited: since we want
to
> charge a cpu cost for every page visited, actually basing that on the
already
> estimated entryPagesFetched and dataPagesFetched would be better,
Thank you for looking at it.
> I looked this over briefly. I think you are correct to charge an
> initial-search cost per searchEntries count, but don't we also need to
> scale up by arrayScans, similar to the "corrections for cache effects"?
>
> + * We model index descent costs similarly
Ronan Dunklau writes:
> The problem I'm trying to solve is that, contrary to btree, gist and sp-gist
> indexes, gin indexes do not charge any cpu-cost for descending the entry tree.
I looked this over briefly. I think you are correct to charge an
initial-search cost per searchEntries count,
Ronan Dunklau writes:
> Following the bug report at [1], I sent the attached patch to pgsql-bugs
> mailing list. I'm starting a thread here to add it to the next commitfest.
That link didn't work easily for me (possibly because it got split across
lines). Here's another one for anybody having
Hello,
Following the bug report at [1], I sent the attached patch to pgsql-bugs
mailing list. I'm starting a thread here to add it to the next commitfest.
The problem I'm trying to solve is that, contrary to btree, gist and sp-gist
indexes, gin indexes do not charge any cpu-cost for descending
18 matches
Mail list logo
