AW: [HACKERS] Bug#48582: psql spends hours computing results it a lready knows (fwd)

From: Zeugswetter Andreas IZ5 <ZeugswetterA(at)wien(dot)spardat(dot)at>
To: "'pgsql-hackers(at)postgreSQL(dot)org'" <pgsql-hackers(at)postgreSQL(dot)org>
Subject: AW: [HACKERS] Bug#48582: psql spends hours computing results it a lready knows (fwd)
Date: 1999-10-29 09:34:44
Message-ID: 219F68D65015D011A8E000006F8590C60339E157@sdexcsrv1.f000.d0188.sd.spardat.at
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-hackers

> The optimizer is perfectly happy with approximate tuple counts, so it
> makes do with stats recorded at the last VACUUM.
>
> This has been discussed quite recently on pg-hackers; see the archives
> for more info.

Yes, the problem is not the optimizer. The problem is the select count(*).
A lot of DB's (like Informix) have a shortcut on this, and even though they
have it,
they don't use it for the optimizer.

If our btrees have an accurate count (deleted rows ?), scanning the smallest
index
would also be alot faster.

Andreas

Browse pgsql-hackers by date

  From Date Subject
Next Message SAKAIDA 1999-10-29 10:45:05 pgbash-1.2.1 released
Previous Message Zakkr 1999-10-29 09:23:54 view vs. inheritance hierarchy (was: Bug(?) in pg_get_ruledef())