Le jeudi 27 août 2009 à 11:36 -0500, Kevin Grittner a écrit : > It is *possible* that if you boost your default_statistics_target and > run ANALYZE (or VACUUM ANALYZE), it will recognize that it isn't a > good idea to read backwards on that index. I would try it and see, if > that's practical for you. If not, you might be able to limit the > plans that the optimizer considers using various techniques, but > that's a bit of a kludge; I'd save it for a last resort. I will try that. > Yeah, that much was pretty apparent to many people from the start. It > was rather frustrating that you weren't listening on that point; I > think that resulted in you wasting time focusing on the wrong things > and not moving in a productive direction sooner. As has been > suggested by someone else, you'll get better results presenting your > problem with as much relevant detail as possible and asking for help > sorting it out, rather than putting too much emphasis on your > preliminary guess as to the cause. Yeah. I will keep that in mind, don't worry. This kind of slow queries on LIMIT seems to happen all the time on Drupal. Maybe it is because the site is not yet going live. Also this means that Drupal on PostgreSQL could rock completely if/when the optimizer has enough information to find the correct plan. If you are interested, I can post on performance ML strange queries with LIMIT that may be interesting after we go life and have enough statistics. Many thanks and bye, Jean-Michel
Attachment:
signature.asc
Description: Ceci est une partie de message =?ISO-8859-1?Q?num=E9riquement?= =?ISO-8859-1?Q?_sign=E9e?=
