I don't have an answer for you, but this report looks suspiciously
similar to the one I posted the other day at
http://archives.postgresql.org/pgsql-hackers/2011-08/msg01224.php,
which, now that I think about it, also manifested itself after the
upgrade to 8.4.8.
On tis, 2011-08-30 at 15:24
On ons, 2011-08-31 at 10:42 +0300, Peter Eisentraut wrote:
I don't have an answer for you, but this report looks suspiciously
similar to the one I posted the other day at
http://archives.postgresql.org/pgsql-hackers/2011-08/msg01224.php,
which, now that I think about it, also manifested itself
Peter Eisentraut pete...@gmx.net writes:
I don't have an answer for you, but this report looks suspiciously
similar to the one I posted the other day at
http://archives.postgresql.org/pgsql-hackers/2011-08/msg01224.php,
which, now that I think about it, also manifested itself after the
On Aug 31, 2011, at 10:47 AM, Tom Lane wrote:
Peter Eisentraut pete...@gmx.net writes:
I don't have an answer for you, but this report looks suspiciously
similar to the one I posted the other day at
http://archives.postgresql.org/pgsql-hackers/2011-08/msg01224.php,
which, now that I think
Ben Chobot be...@silentmedia.com writes:
Tom, if there's anything else we can provide that might you out, let me know.
If you could extract a self-contained test case for the bad estimation,
that would be useful.
regards, tom lane
--
Sent via pgsql-general mailing list
On Aug 31, 2011, at 11:10 AM, Tom Lane wrote:
Ben Chobot be...@silentmedia.com writes:
Tom, if there's anything else we can provide that might you out, let me know.
If you could extract a self-contained test case for the bad estimation,
that would be useful.
OK, we'll pull something
On Aug 31, 2011, at 11:53 AM, Ben Chobot wrote:
On Aug 31, 2011, at 11:10 AM, Tom Lane wrote:
Ben Chobot be...@silentmedia.com writes:
Tom, if there's anything else we can provide that might you out, let me
know.
If you could extract a self-contained test case for the bad estimation,
We recently took a copy of our production data (running on 8.4.2), scrubbed
many data fields, and then loaded it onto a qa server (running 8.4.8). We're
seeing some odd planner performance that I think might be a bug, though I'm
hoping it's just idiocy on my part. I've analyzed things and