-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1
Tom Lane wrote:
| Dennis Bjorklund <[EMAIL PROTECTED]> writes: | |>In this plan it estimates to get 481 but it got 22477. So the estimation |>was very wrong. You can increase the statistics tarhet on the login_time |>and it will probably be better (after the next analyze). | | | Given the nature of the data (login times), I'd imagine that the problem | is simply that he hasn't analyzed recently enough. A bump in stats | target may not be needed, but he's going to have to re-analyze that | column often if he wants this sort of query to be estimated accurately, | because the fraction of entries later than a given time T is *always* | going to be changing.
Well know that I think about it, I felt my shoulders covered by pg_autovacuum but looking at the log I see that table never analyzed! Aaargh.
I already applied the patch for the autovacuum but evidently I have to make it more aggressive, I'm sorry that I can not made him more aggressive only for this table.
Thank you all.
Regards Gaetano Mendola
-----BEGIN PGP SIGNATURE----- Version: GnuPG v1.2.4 (MingW32) Comment: Using GnuPG with Thunderbird - http://enigmail.mozdev.org
iD8DBQFBAU3g7UpzwH2SGd4RAhbEAKDLbKXLGRqphBbfyBh6cu7QoqFQhACfdDtu cGS0K1UuTuwTDp4P2JjQ30A= =aepf -----END PGP SIGNATURE-----
---------------------------(end of broadcast)--------------------------- TIP 9: the planner will ignore your desire to choose an index scan if your joining column's datatypes do not match
