Tom Lane wrote:
Joachim Wieland [EMAIL PROTECTED] writes:
As said before, it only happens with make installcheck, not make check.
Curious. I'm not sure if the buildfarm tries to isolate the
installation against its locale environment --- can you check the locale
used by the install
On Fri, May 25, 2007 at 05:58:58PM -0400, Tom Lane wrote:
Would you try inserting a vacuum verbose pg_constraint into the test
as well? Maybe that will tell something relevant.
It's weird. I have run a make check with the serial schedule and a regular
installcheck on a fresh DB. Vacuum verbose
Tom Lane wrote:
Gregory Stark [EMAIL PROTECTED] writes:
Perhaps this comes down to 64 vs 32 bit datum and aligments and therefore
different size tables which because the planner does the lseek to measure the
table size shows up as different estimates for sequential scan costs?
But we've got
On Sat, May 26, 2007 at 11:40:52AM +0100, Heikki Linnakangas wrote:
But we've got plenty of both in the buildfarm, and none of them are
showing this failure. So I'm curious to know what's really different
about Joachim's installation. It seems he must have a pg_constraint
table enough larger
Joachim Wieland [EMAIL PROTECTED] writes:
On Sat, May 26, 2007 at 11:40:52AM +0100, Heikki Linnakangas wrote:
Or maybe some non-default values in postgresql.conf? Like random_page_cost?
No, I use what initdb creates:
Curiouser and curiouser. You still get the indexscan as preferred if
you
On Sat, May 26, 2007 at 12:14:14PM -0400, Tom Lane wrote:
Curiouser and curiouser. You still get the indexscan as preferred if
you EXPLAIN the query after the regression tests complete, right?
Could you step through cost_seqscan and see how it's arriving at such
a high value?
Ok... I figured
For some reason the cluster test fails on my machine due to a different
order of the result rows when I run installcheck instead of check. Is
there a problem adding an ORDER BY to it?
Joachim
Index: src/test/regress/sql/cluster.sql
Joachim Wieland [EMAIL PROTECTED] writes:
For some reason the cluster test fails on my machine due to a different
order of the result rows when I run installcheck instead of check. Is
there a problem adding an ORDER BY to it?
We should find out why that's happening rather than just throwing an
On Fri, May 25, 2007 at 10:33:41AM -0400, Tom Lane wrote:
We should find out why that's happening rather than just throwing an
ORDER BY at it. Considering the number of buildfarm machines that
aren't showing any such problem, there must be something odd about
yours. What's the platform?
Joachim Wieland wrote:
On Fri, May 25, 2007 at 10:33:41AM -0400, Tom Lane wrote:
We should find out why that's happening rather than just throwing an
ORDER BY at it. Considering the number of buildfarm machines that
aren't showing any such problem, there must be something odd about
Joachim Wieland [EMAIL PROTECTED] writes:
EXPLAIN SELECT conname FROM pg_constraint WHERE conrelid =
'clstr_tst'::regclass;
QUERY PLAN
---
Index Scan
Joachim Wieland [EMAIL PROTECTED] writes:
As said before, it only happens with make installcheck, not make check.
Curious. I'm not sure if the buildfarm tries to isolate the
installation against its locale environment --- can you check the locale
used by the install case?
Tom Lane [EMAIL PROTECTED] writes:
This is in the regression database after a completed regression run, so
it's possible that it's a bit different state from what's seen at the
instant the cluster test was running, but it sure looks like the
expected results are what you get from a seqscan.
Gregory Stark [EMAIL PROTECTED] writes:
Perhaps this comes down to 64 vs 32 bit datum and aligments and therefore
different size tables which because the planner does the lseek to measure the
table size shows up as different estimates for sequential scan costs?
But we've got plenty of both in
On Fri, May 25, 2007 at 12:09:43PM -0400, Tom Lane wrote:
This is in the regression database after a completed regression run, so
it's possible that it's a bit different state from what's seen at the
instant the cluster test was running, but it sure looks like the
expected results are what you
15 matches
Mail list logo
