Re: Fix gin index cost estimation

From: Ronan Dunklau <ronan(dot)dunklau(at)aiven(dot)io>
To: Alexander Korotkov <aekorotkov(at)gmail(dot)com>, Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us>
Cc: Michael Paquier <michael(at)paquier(dot)xyz>, pgsql-hackers(at)lists(dot)postgresql(dot)org
Subject: Re: Fix gin index cost estimation
Date: 2022-12-02 10:19:11
Message-ID: 13151261.uLZWGnKmhe@aivenlaptop
Views: Raw Message | Whole Thread | Download mbox | Resend email
Lists: pgsql-hackers

Le mardi 25 octobre 2022, 16:18:57 CET Tom Lane a écrit :
> Alexander Korotkov <aekorotkov(at)gmail(dot)com> 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-trees CPU cost and replacing
> > existing
> > CPU estimation altogether.
> Great idea, if someone is willing to do it ...
> regards, tom lane


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
- additionally, a charge is applied per page in both the entry tree and
posting trees / lists
- instead of charging the quals to each tuple, charge them per entry only. We
still charge cpu_index_tuple_cost per tuple though.

With those changes, no need to tweak the magic number formula estimating the
number of pages. Maybe we can come up with something better for estimating
those later on ?

Best regards,

Ronan Dunklau

Attachment Content-Type Size
v3-0001-Fix-gin-costing.patch text/x-patch 5.2 KB

In response to


Browse pgsql-hackers by date

  From Date Subject
Next Message Amit Langote 2022-12-02 10:40:42 Re: generic plans and "initial" pruning
Previous Message Alvaro Herrera 2022-12-02 09:59:54 Re: ExecRTCheckPerms() and many prunable partitions