Gregory Stark <stark@enterprisedb.com> 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
more?
regards, tom lane
