-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1
We don't have to do this immediately, but would there be any objection
to removing the user_id column from the user_newtalk table and using
that table only for anon IP addresses?
It just strikes me as a bizarre structure (each row contains data in
*either* user_id or user_ip), and we already load up the whole row from
the user table when dealing with a logged-in user. If we put the
user_newtalk column back into user, we can cut out a query from each
logged-in page view. Not much, sure, but it seems redundant as it is.
- -- brion vibber (brion @ pobox.com)
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.2.2 (GNU/Linux)
iD8DBQE+0TcfxVlOmwh1xjgRAkNVAJ9KQpiro3JfeWmZa8VNIOzlw7GhDwCePDEh
8Ml5K6CFDenN1QcHNB+jztU=
=Lx1g
-----END PGP SIGNATURE-----
Hash: SHA1
We don't have to do this immediately, but would there be any objection
to removing the user_id column from the user_newtalk table and using
that table only for anon IP addresses?
It just strikes me as a bizarre structure (each row contains data in
*either* user_id or user_ip), and we already load up the whole row from
the user table when dealing with a logged-in user. If we put the
user_newtalk column back into user, we can cut out a query from each
logged-in page view. Not much, sure, but it seems redundant as it is.
- -- brion vibber (brion @ pobox.com)
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.2.2 (GNU/Linux)
iD8DBQE+0TcfxVlOmwh1xjgRAkNVAJ9KQpiro3JfeWmZa8VNIOzlw7GhDwCePDEh
8Ml5K6CFDenN1QcHNB+jztU=
=Lx1g
-----END PGP SIGNATURE-----