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, and
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 ar
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 number
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 mac
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, so
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 wri
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 data-tr
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, what's
> > 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 pro
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 he
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 o
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, ins
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 t
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, but
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 s
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
