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 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 than "normal" to discourage the seqscan, but where
did that come from?  There's only one row in pg_constraint in standard
template0 --- could he be working with a custom system that has many

Or maybe some non-default values in postgresql.conf? Like random_page_cost?

  Heikki Linnakangas

---------------------------(end of broadcast)---------------------------
TIP 9: In versions below 8.0, the planner will ignore your desire to
      choose an index scan if your joining column's datatypes do not

Reply via email to