Hi,
I am curious as to why this occurs. Why does an = change the query plan so
drastically?
When my query is:
Select count(*) from View_A WHERE tradedate = '20070801';
The query plan is as below: I see that the scan on the alloctbl is being
indexed on k_alloctbl_blockid_status
-> Bitmap Index
Tom Lane-2 wrote:
>
> pgdba <[EMAIL PROTECTED]> writes:
>> Tom Lane-2 wrote:
>> -> Bitmap Index Scan on slog_gri_idx
>> (cost=0.00..82.26
>> rows=2870 width=0) (actual time=41.306..41.306 rows=83538 loops=1)
>> Index Cond: ((gid = 1) AND (rule = ANY
>> ('{1,2,8,9,10}'::integer[])) AND (CA
pgdba <[EMAIL PROTECTED]> writes:
> Tom Lane-2 wrote:
> -> Bitmap Index Scan on slog_gri_idx
> (cost=0.00..82.26
> rows=2870 width=0) (actual time=41.306..41.306 rows=83538 loops=1)
> Index Cond: ((gid = 1) AND (rule = ANY
> ('{1,2,8,9,10}'::integer[])) AND (CASE WHEN (rule = ANY
> ('{8,9}'::
Hi Tom,
Tom Lane-2 wrote:
>
> pgdba <[EMAIL PROTECTED]> writes:
>> -> Bitmap Heap Scan on slog (cost=82.98..6434.62 rows=2870
>> width=61) (actual time=50.235..1237.948 rows=83538 loops=1)
>> Recheck Cond: ((gid = 1) AND (rule = ANY
>> ('{1,2,8,9,10}'::integ
Csaba Nagy <[EMAIL PROTECTED]> writes:
> db=# analyze verbose temp_table_a;
> INFO: analyzing "public.temp_table_a"
> INFO: "temp_table_a": scanned 3000 of 655299 pages, containing 1887000 live
> rows and 0 dead rows; 3000 rows in sample, 412183071 estimated total rows
Hmm. So the bottom line
> Csaba, please can you copy that data into fresh tables, re-ANALYZE and
> then re-post the EXPLAINs, with stats data.
Here you go, fresh experiment attached.
Cheers,
Csaba.
db=# \d temp_table_a
Table "public.temp_table_a"
Column | Type | Modifiers
++---
a |
pgdba <[EMAIL PROTECTED]> writes:
> -> Bitmap Heap Scan on slog (cost=82.98..6434.62 rows=2870
> width=61) (actual time=50.235..1237.948 rows=83538 loops=1)
> Recheck Cond: ((gid = 1) AND (rule = ANY
> ('{1,2,8,9,10}'::integer[])) AND (CASE WHEN (rule = ANY
> (
Hi, I am having some trouble understanding a plan and was wondering if anyone
could guide me. The query in question here seems to be showing some
incorrect row counts. I have vacuumed and analyzed the table, but the
estimate versus the actual total seems to be way out (est 2870 vs actual
85k). Per
This has been saved for the 8.4 release:
http://momjian.postgresql.org/cgi-bin/pgpatches_hold
---
Tom Lane wrote:
> Michael Fuhr <[EMAIL PROTECTED]> writes:
> > On Sat, Oct 29, 2005 at 09:49:47AM -0500, Bruno Wolff
