Обсуждение: Removing width from EXPLAIN
-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 I remember there was some talk about removing the width=xxx part from the EXPLAIN plans. Any movement towards this? I myself would like to see this happen as it does not provide useful information and makes the already busy explain plan that much busier. Anyone have a good argument to keep this around? Can we at least make it display/not display with a parameter? - -- Greg Sabino Mullane greg@turnstep.com PGP Key: 0x14964AC8 200305190919 -----BEGIN PGP SIGNATURE----- Comment: http://www.turnstep.com/pgp.html iD8DBQE+yNrZvJuQZxSWSsgRAq37AKCFAwZV2mTuoyULDrl6EFpXsBS1WACfQedY I0+ySFm3HWhVyM698a75e8w= =z/9s -----END PGP SIGNATURE-----
"Greg Sabino Mullane" <greg@turnstep.com> writes:
> I remember there was some talk about removing the width=xxx part from the
> EXPLAIN plans. Any movement towards this?
You didn't hear that from me.
> I myself would like to see this
> happen as it does not provide useful information
Yes it does: the width * number of rows is a critical element in cost
estimation for sorts and hashes.
regards, tom lane
-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 I guess I was thinking about this: http://groups.google.com/groups?selm=10897.953919427%40sss.pgh.pa.us "Average width is pretty bogus because the thing really doesn't haveany idea of the average length of variable-length columns. I'm thinkingabout improving that in the future, but it may not be worth the trouble,because the width isn't usedfor very much." I also think that it is used that much: if you look at all the EXPLAINS that have come across the various lists over the years, very few (if any) utilize the "width" in any important way. It's important for computing the cost, but I would like to suggest that the extra "noise" should be off by default as most people never make use of it, and an EXPLAIN ANALYZE is already quite verbose. - -- Greg Sabino Mullane greg@turnstep.com PGP Key: 0x14964AC8 200305201143 -----BEGIN PGP SIGNATURE----- Comment: http://www.turnstep.com/pgp.html iD8DBQE+ynErvJuQZxSWSsgRAsiKAKDXEaCPnhq8koIhnFNNPfm5HzhA9gCgszok bBRBoL4Uoe8gqXzizeLlU2o= =I1sV -----END PGP SIGNATURE-----
greg@turnstep.com writes: > I guess I was thinking about this: > http://groups.google.com/groups?selm=10897.953919427%40sss.pgh.pa.us > "Average width is pretty bogus because the thing really doesn't have > any idea of the average length of variable-length columns. I'm thinking > about improving that in the future, but it may not be worth the trouble, > because the width isn't used for very much." That comment predated 7.0, which is a long time ago. We now have statistics about actual average widths of columns, so the estimates are not nearly as bogus as they used to be. And with the expanded scope for hash-based query plans in 7.4, I think the estimated size of hash tables will become an even more interesting tidbit than it is now. > I also think that it is used that much: if you look at all the EXPLAINS > that have come across the various lists over the years, very few (if any) > utilize the "width" in any important way. It's important for computing > the cost, but I would like to suggest that the extra "noise" should be > off by default as most people never make use of it, and an EXPLAIN ANALYZE > is already quite verbose. But EXPLAIN has always included a lot of info that the man in the street wouldn't know how to interpret. I don't think making it less complete is going to help anyone. regards, tom lane
-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 > That comment predated 7.0, which is a long time ago. Yep, that's old all right. Don't know how such an old thread stuck in my head for so long. :) > ... > But EXPLAIN has always included a lot of info that the man in the street > wouldn't know how to interpret. I don't think making it less complete > is going to help anyone. Fair enough, I'm happy with the way it is then. FWIW, I tried to look up the history of plan_width in the src/backend tree, but anoncvs is still down. :( - -- Greg Sabino Mullane greg@turnstep.com PGP Key: 0x14964AC8 200305201517 -----BEGIN PGP SIGNATURE----- Comment: http://www.turnstep.com/pgp.html iD8DBQE+yoBjvJuQZxSWSsgRAoVsAJ9ADOqbejHK64byCsdegiINarTNpQCg0goN rvq9SAPg40Lhorp3e4f1F+w= =ejl/ -----END PGP SIGNATURE-----
On Tue, May 20, 2003 at 08:14:12PM -0000, greg@turnstep.com wrote: > > But EXPLAIN has always included a lot of info that the man in the street > > wouldn't know how to interpret. I don't think making it less complete > > is going to help anyone. > > Fair enough, I'm happy with the way it is then. FWIW, I tried to look up > the history of plan_width in the src/backend tree, but anoncvs is still down. :( FWIW, if you want to try such things, I strongly recommend using CVSup. It's not exactly easy to setup, but it's really nice to have the complete repository. Joe Conway has some RPMs that can be of use in www.joeconway.com, if you are in a Redhat-ish system. Make sure you install ezm3 first... -- Alvaro Herrera (<alvherre[a]dcc.uchile.cl>) Jajaja! Solo hablaba en serio!
I ended up doing that too.. But of course the diffs now include those make file changes (DOH!). On Wed, 2003-05-21 at 14:53, Alvaro Herrera wrote: > On Wed, May 21, 2003 at 02:40:17PM -0400, Rod Taylor wrote: > > > FWIW, if you want to try such things, I strongly recommend using CVSup. > > > It's not exactly easy to setup, but it's really nice to have the > > > complete repository. > > > > How did you manage to get the earthdistance and libpqxx items? > > Makefiles are broken as they don't exist in the pgsql module. > > Oh, I didn't. In fact, I took them out of contrib/Makefile. -- Rod Taylor <rbt@rbt.ca> PGP Key: http://www.rbt.ca/rbtpub.asc
On Wed, May 21, 2003 at 02:40:17PM -0400, Rod Taylor wrote: > > FWIW, if you want to try such things, I strongly recommend using CVSup. > > It's not exactly easy to setup, but it's really nice to have the > > complete repository. > > How did you manage to get the earthdistance and libpqxx items? > Makefiles are broken as they don't exist in the pgsql module. Oh, I didn't. In fact, I took them out of contrib/Makefile. -- Alvaro Herrera (<alvherre[a]dcc.uchile.cl>) "El conflicto es el camino real hacia la union"
> FWIW, if you want to try such things, I strongly recommend using CVSup. > It's not exactly easy to setup, but it's really nice to have the > complete repository. How did you manage to get the earthdistance and libpqxx items? Makefiles are broken as they don't exist in the pgsql module. Followed: http://developer.postgresql.org/docs/postgres/cvsup.html -- Rod Taylor <rbt@rbt.ca> PGP Key: http://www.rbt.ca/rbtpub.asc
Rod Taylor wrote: > How did you manage to get the earthdistance and libpqxx items? > Makefiles are broken as they don't exist in the pgsql module. > > Followed: > http://developer.postgresql.org/docs/postgres/cvsup.html That needs to be updated. When Marc moved those out of the main repository, he posted a correction -- -# complete distribution, including all below -pgsql +# complete distribution, including all below +repository -- should take care of the missing folders. Joe
On Wed, May 21, 2003 at 08:39:03PM -0700, Joe Conway wrote: > Rod Taylor wrote: > >Followed: > >http://developer.postgresql.org/docs/postgres/cvsup.html > > That needs to be updated. When Marc moved those out of the main > repository, he posted a correction -- > > -# complete distribution, including all below > -pgsql > +# complete distribution, including all below > +repository I see. I now get earthdistance and libpqxx in the cvsup repository, but to get them into the CVS copy checked out from there, I have to manually check them out: cd src/interfaces cvs -d /home/alvherre/cvsup checkout interfaces/libpqxx But it works! Thank again, Joe. -- Alvaro Herrera (<alvherre[a]dcc.uchile.cl>) Major Fambrough: You wish to see the frontier? John Dunbar: Yes sir, before it's gone.
Alvaro Herrera wrote: > I see. I now get earthdistance and libpqxx in the cvsup repository, but > to get them into the CVS copy checked out from there, I have to manually > check them out: > > cd src/interfaces > cvs -d /home/alvherre/cvsup checkout interfaces/libpqxx > Actually, I just do `cvs co pgsql` and I get everything in one shot. Joe