"Robert E. Bruccoleri" wrote:
>
> >
> > what are the cost estimates when you run explain with seqscan disabled ?
> > do => SET ENABLE_SEQSCAN TO OFF;
> > see:
> >
>(http://www.postgresql.org/devel-corner/docs/admin/runtime-config.htm#RUNTIME-CONFIG-OPTIMIZER)
>
> Here's the result from EXPLAIN:
Dear Hannu,
>
> "Robert E. Bruccoleri" wrote:
> >
> > Dear Hannu,
> > >
> > > "Robert E. Bruccoleri" wrote:
> > > >
> > > > explain select count(*) from comparisons_4 where code = 80003;
> > > > NOTICE: QUERY PLAN:
> > > >
> > > > Aggregate (cost=15659.29..15659.29 rows=1 width=0)
> > > > ->
"Robert E. Bruccoleri" wrote:
>
> Dear Hannu,
> >
> > "Robert E. Bruccoleri" wrote:
> > >
> > > explain select count(*) from comparisons_4 where code = 80003;
> > > NOTICE: QUERY PLAN:
> > >
> > > Aggregate (cost=15659.29..15659.29 rows=1 width=0)
> > > -> Seq Scan on comparisons_4 (cost=0.
Dear Hannu,
>
> "Robert E. Bruccoleri" wrote:
> >
> > explain select count(*) from comparisons_4 where code = 80003;
> > NOTICE: QUERY PLAN:
> >
> > Aggregate (cost=15659.29..15659.29 rows=1 width=0)
> > -> Seq Scan on comparisons_4 (cost=0.00..15640.81 rows=7391 width=0)
> >
> > EXPLAIN
"Robert E. Bruccoleri" wrote:
>
> explain select count(*) from comparisons_4 where code = 80003;
> NOTICE: QUERY PLAN:
>
> Aggregate (cost=15659.29..15659.29 rows=1 width=0)
> -> Seq Scan on comparisons_4 (cost=0.00..15640.81 rows=7391 width=0)
>
> EXPLAIN
What is the type of field "code
Zeugswetter Andreas SB <[EMAIL PROTECTED]> writes:
> More importantly, PostgreSQL 6.5.3 works very, very well without
> VACUUM'ing.
>>
>> 6.5 effectively assumes that "foo = constant" will select exactly one
>> row, if it has no statistics to prove otherwise.
> I thought we had agreed upon a de
> > More importantly, PostgreSQL 6.5.3 works very, very well without
> > VACUUM'ing.
>
> 6.5 effectively assumes that "foo = constant" will select exactly one
> row, if it has no statistics to prove otherwise.
I thought we had agreed upon a default that would still use
the index in the above ca
Dear Tom,
> You can't afford to run a VACUUM ANALYZE even once in the lifetime of
> the table?
Not very often at best, and certainly not routinely. Some of my
tables exceed 10GB and have multiple indices.
However, to test your suggestion, I modified my performance test
script to "VACUUM ANALYZE
"Robert E. Bruccoleri" wrote:
You can try starting postmaster with the "-o -fs" option. This will disable sequential
scans if there is an index. There is also an environment variable you can set, prior
to the operation. I have run into this same problem.
> Dear Tom,
> I am writing to
[EMAIL PROTECTED] (Robert E. Bruccoleri) writes:
> I have followed the discussion in pgsql-hackers over the previous
> months and others have noted some performance problems, and the response
> has typically been to VACUUM the tables. Unfortunately, this is not a
> practical option for my ap
10 matches
Mail list logo
