Patrice Beliveau wrote:
> Thanks,
>
> I'm already doing a vacuum full every night on all database, but the
> REINDEX fix it and now it's working fine
Are you sure it was the REINDEX? The plan was using a sequential scan.
> But this raise a question
>
> 1) This table is cleared every night and r
Thanks,
I'm already doing a vacuum full every night on all database, but the REINDEX
fix it and now it's working fine
But this raise a question
1) This table is cleared every night and recomputed, does this mean that I
should REINDEX every night also
2) Why this thing didn't happen in the ot
Patrice Beliveau wrote:
> I have a database in a production server (8.1.9) with to schema
> containing the sames table same index, same every thing, but with
> different data. When I execute a query in one schema, it take much more
> time to execute then the other schema.
[snip]
> I'm wondering whe
I have a database in a production server (8.1.9) with to schema
containing the sames table same index, same every thing, but with
different data. When I execute a query in one schema, it take much more
time to execute then the other schema. I've issue the query plan and
it's different from one
Radhika S wrote:
> 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:
> ...
> But when my query is:
> Select count(*) from View_A WHERE tradedate B
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
