On Wed, 27 Feb 2002 at 22:57, Tom Lane wrote:
> Also, to put the rubber to the road: if you force an indexscan by
> doing "set enable_seqscan = off", does it get faster or slower?
> (EXPLAIN ANALYZE would be useful here.)
I've just found a case where forcing indexscans results in much higher
spe
Ok, so this morning after the automated nightly vacuum -z -v on the database,
ELTE no longer appears in the pg_stats table, and the index is picked no
problem. The table data has not changed since last eve.
However, now there is a new symbol which is behaving the same way--I. This
symbol was
On Thu, 28 Feb 2002 at 09:51, Tom Lane wrote:
> Reinhard Max <[EMAIL PROTECTED]> writes:
> > I've just found a case where forcing indexscans results in much higher
> > speed.
>
> > -> Index Scan using foo_pkey on foo
> > (cost=0.00..25153.18 rows=352072 width=4)
> >
Reinhard Max <[EMAIL PROTECTED]> writes:
> I've just found a case where forcing indexscans results in much higher
> speed.
> -> Index Scan using foo_pkey on foo
> (cost=0.00..25153.18 rows=352072 width=4)
> (actual time=0.03..157.57 rows=38432 loops=1)
The ma
Reinhard Max <[EMAIL PROTECTED]> writes:
>> The major estimation error is evidently in this indexscan. What
>> statistics does pg_stats show for this table?
> See attached file.
Okay. It looks like foo.id has a pretty strong but not perfect
descending order (the correlation statistic is -0.563
On Thu, 28 Feb 2002 at 10:15, Tom Lane wrote:
> Okay. It looks like foo.id has a pretty strong but not perfect
> descending order (the correlation statistic is -0.563276). The
> planner is evidently not rating that effect strongly enough.
Yes, that seems to be the reason. When I try
S
> Are these the addtional values you wanted to see?
Yes, but I just noticed something else strange:
> -> Index Scan using foo2_pkey on foo2
> (cost=0.00..10387.79 rows=352072 width=4)
> (actual time=0.26..174.32 rows=38432 loops=1)
The actual rows re
Hi,
On Thu, 28 Feb 2002 at 16:10, Tom Lane wrote:
> > -> Index Scan using foo2_pkey on foo2
> > (cost=0.00..10387.79 rows=352072 width=4)
> > (actual time=0.26..174.32 rows=38432 loops=1)
>
> The actual rows read from this indexscan seem to be many fe
