Re: Query planner / Analyse statistics bad estimate rows=1 with maximum statistics 10000 on PostgreSQL 10.2

From: Jeff Janes <jeff(dot)janes(at)gmail(dot)com>
To: Mark <mwchambers(at)gmail(dot)com>
Cc: pgsql-general(at)lists(dot)postgresql(dot)org
Subject: Re: Query planner / Analyse statistics bad estimate rows=1 with maximum statistics 10000 on PostgreSQL 10.2
Date: 2018-12-23 02:56:53
Message-ID: CAMkU=1xe=d66bz56mw0Zs8VNa1yh7rNpGQxzsrDidAyfCr+Pwg@mail.gmail.com
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-general pgsql-hackers

>
>
> - Does the analyse output below mean that it only scanned 51538 of 65463
> rows in the table? Is school_id 36 just being missed in the sample? (This
> happens when the analyse is repeated )
>

Is there a transaction which had deleted all of school_id=36, and then was
just left open indefinitely without either committing or rolling back?

That would explain it, and I don't know of anything else that could. The
deleted but not committed tuples are still live, but don't get sampled.

Cheers,

Jeff

In response to

Responses

Browse pgsql-general by date

  From Date Subject
Next Message Mitar 2018-12-23 06:09:49 Re: Watching for view changes
Previous Message Rob Sargent 2018-12-22 21:16:05 Re: Watching for view changes

Browse pgsql-hackers by date

  From Date Subject
Next Message Michael Paquier 2018-12-23 08:04:53 Re: pgsql: Update ssl test certificates and keys
Previous Message Jeff Janes 2018-12-23 02:26:00 Re: Make relcache init write errors not be fatal