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 shows the same output on both but
different plans are chosen.


Joachim


---------------------------(end of broadcast)---------------------------
TIP 4: Have you searched our list archives?

http://archives.postgresql.org

Tom Lane wrote:
> 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?

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

--
Heikki Linnakangas
EnterpriseDB http://www.enterprisedb.com

---------------------------(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
match

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 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?

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

No, I use what initdb creates:

$ cat postgresql.conf | grep ^[a-zA-Z]
max_connections = 100 # (change requires restart)
shared_buffers = 24MB # min 128kB or max_connections*16kB
max_fsm_pages = 153600 # min max_fsm_relations*16, 6 bytes each
datestyle = 'iso, dmy'
lc_messages = 'es_ES@euro' # locale for system error message
lc_monetary = 'es_ES@euro' # locale for monetary formatting
lc_numeric = 'es_ES@euro' # locale for number formatting
lc_time = 'es_ES@euro' # locale for time formatting


Joachim



---------------------------(end of broadcast)---------------------------
TIP 7: You can help support the PostgreSQL project by donating at

http://www.postgresql.org/about/donate

Joachim Wieland <joe@mcknight.de> 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 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?

regards, tom lane

---------------------------(end of broadcast)---------------------------
TIP 7: You can help support the PostgreSQL project by donating at

http://www.postgresql.org/about/donate

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 it out... When I was doing the guc patch I modified my
startdb.sh script such that it passes settings on the command line to
postmaster. There I changed seq_page_cost. I know that I have removed those
settings on my laptop computer since then but I seem to have copied it here
on my other machine at that time and so it started with a different
seq_page_cost... *blushing*...

Sorry for the noise... Interesting though that it only made a difference to
the cluster test...


Joachim



---------------------------(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
match

Tom Lane wrote:
> Joachim Wieland <joe@mcknight.de> 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?
>

Buildfarm does:

@initout = `"bin/initdb" --no-locale data 2>&1`;

If it didn't we'd have had problems with much more for much longer.


cheers

andrew

---------------------------(end of broadcast)---------------------------
TIP 4: Have you searched our list archives?

http://archives.postgresql.org