Horton

Re: distinguish index cost component from table component

Justin Pryzby <pryzby@telsasoft.com>

View thread View on postgr.es
From: Justin Pryzby <pryzby@telsasoft.com>
To: Jeff Janes <jeff.janes@gmail.com>
Cc: pgsql-performance@postgresql.org
Date: 2020-01-03T16:03:15Z
Lists: pgsql-hackers, pgsql-performance

Attachments

On Fri, Jan 03, 2020 at 09:33:35AM -0500, Jeff Janes wrote:
> Of course this doesn't really answer your question, as the
> separately-reported costs of a bitmap heap and bitmap index scan are
> unlikely to match what the costs would be of a regular index scan, if they
> were reported separately.

I think the cost of index component of bitmap scan would be exactly the same
as the cost of the original indexscan.

>> Or maybe explain should report it.
> 
> I wouldn't be optimistic about getting such a backwards-incompatible change
> accepted (plus it would surely add some small accounting overhead, which
> again would probably not be acceptable). But if you do enough tuning work,
> perhaps it would be worth carrying an out-of-tree patch to implement that.
> I wouldn't be so interested in writing such a patch, but would be
> interested in using one were it available somewhere.

I did the attached in the simplest possible way.  If it's somehow possible get
the path's index_total_cost from the plan, then there'd be no additional
overhead.

Justin

Commits

  1. Doc: Fix list of storage parameters available for ALTER TABLE

  2. Enhance docs for ALTER TABLE lock levels of storage parms

  3. Reduce lock levels for table storage params related to planning

  4. Reduce lock levels for ALTER TABLE SET autovacuum storage options

  5. Reduce lock levels of some ALTER TABLE cmds

  6. Reduce lock levels of CREATE TRIGGER and some ALTER TABLE, CREATE RULE actions.

  7. Support ALTER TABLESPACE name SET/RESET ( tablespace_options ).