Thank you Tom. The cron job for vacuum+analyze was not installed on the host.
(I had this idea some seconds after posting)
After vacuum+analyze the performance is good. I am happy.
Nevertheless, on a different host with nearly the same data, a index scan is
used.
foo_hostone_foo=# explain analy
Sam Mason writes:
> On Thu, Apr 16, 2009 at 11:29:25AM -0400, Tom Lane wrote:
>> , a full table indexscan isn't going to be particularly fast in
>> any case; it's often the case that seqscan-and-sort is the right
>> decision.
> Is PG capable of "skipping" over duplicate values using an index?
No
On Thu, Apr 16, 2009 at 11:29:25AM -0400, Tom Lane wrote:
> , a full table indexscan isn't going to be particularly fast in
> any case; it's often the case that seqscan-and-sort is the right
> decision.
Is PG capable of "skipping" over duplicate values using an index?
For example, if I've got a t
Thomas Guettler writes:
> why does the statement take so long? The column 'lieferant' is indexed. But
> a sequential scan gets done.
It might have something to do with the fact that the planner's idea of
the size of the table is off by a factor of more than 100:
> -> Seq Scan on foo_ab
wasn't that improved now in 8.4, and before that on 8.3 ?
still there are some funny things with distinct/group by .
for instance, try
select count(distinct foo) from bar; vs
select count(1) from (select distinct foo from bar) f;
:)
I am not sure it pg was able to use index for that in 8.2.
--
Hi,
why does the statement take so long? The column 'lieferant' is indexed. But
a sequential scan gets done.
foo_egs_foo=# explain analyze SELECT DISTINCT "foo_abc_abc"."lieferant" FROM
"foo_abc_abc";
QUERY PLAN
--
