Are cost estimates based on asserts?

From: "Kevin Grittner" <Kevin(dot)Grittner(at)wicourts(dot)gov>
To: <pgsql-hackers(at)postgresql(dot)org>
Subject: Are cost estimates based on asserts?
Date: 2005-10-12 19:54:15
Message-ID: s34d23a4.024@gwmta.wicourts.gov
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-hackers

I'm running right now with a dev build which was configured with
--enable-cassert (and --enable-debug). Just out of curiosity, I re-ran
the query which chose the sort and mergejoin over the (faster) nested
index scan. The results seem interesting, although I'd need more tests
to consider them entirely reliable. I've divided the actual run time
(in ms) by the cost estimate, to come up with the ratio of ms per unit
of estimated cost. I'll round to three significant digits, based on
observed variation from one test to another.

==============================
WITH --enable-cassert
==============================

uncached sort/merge: 0.194
uncached nested scan: 0.288

cached sort/merge: 0.0340
cached nested scan: 0.0560

==============================
WITHOUT --enable-cassert
==============================

uncached sort/merge: 0.182
uncached nested scan: 0.0478

cached sort/merge: 0.0256
cached nested scan: 0.00494

This shows me that when assertions are being tested, the cost estimates
are slightly skewed to favor nested scans. When assertions are not
tested, costs seem to be significantly distorted in favor of the
sort/merge. The assertion load on the index scan seems to be extreme.
It'll take some time to make sure that I can reproduce this, but I
wanted to put this out there for comment and possible independent
confirmation.

-Kevin

Responses

Browse pgsql-hackers by date

  From Date Subject
Next Message David Fetter 2005-10-12 19:54:19 Comments on columns in the pg_catalog tables/views
Previous Message Jonah H. Harris 2005-10-12 19:29:27 Re: slow IN() clause for many cases