eau [mailto:[EMAIL PROTECTED]
Sent: 02 September 2008 14:56
To: David West
Cc: pgsql-performance@postgresql.org
Subject: Re: [PERFORM] limit clause breaks query planner?
"David West" writes:
> INFO: "jbpm_taskinstance": moved 1374243 row versions, truncated 166156
to
&g
>A single VACUUM may not report how bloated your table is, if it's
>been VACUUM'ed some before, but not frequently enough. If you
>have time for it, and you can afford a full lock on the table,
>only a VACUUM FULL VERBOSE will tell you the previous bloat (the
>"table .. truncated to .." line IIRC)
"Aggregate (cost=180859.91..180859.92 rows=1 width=0) (actual
time=4358.316..4358.318 rows=1 loops=1)"
" -> Bitmap Heap Scan on jbpm_taskinstance (cost=23832.88..178121.49
rows=1095365 width=0) (actual time=377.206..2929.735 rows=1020062 loops=1)"
" Recheck C
e the limit when deciding the best index to use
- in this simple query wouldn't the best plan to use always be the same
with or without a limit?
Thanks to all of you for your interest in my problem
David
-Original Message-
From: Guillaume Cottenceau [mailto:[EMAIL PROTECTED]
Sen
(actual time=466.545..466.545 rows=1020084 loops=1)"
"Index Cond: ((B)::text = '21'::text)"
"Total runtime: 8940.119 ms"
In this case it goes for the correct index. It appears that the query planner
makes very simplistic assumptions when it comes to LIMIT?
T
Hi,
I have a single table with about 10 million rows, and two indexes. Index A
is on a column A with 95% null values. Index B is on a column B with about
10 values, ie. About a million rows of each value.
When I do a simple query on the table (no joins) with the following
condition:
A is
