"
"Seq Scan on conversion_table c (cost=0.00..29990.83
rows=1094820 width=66)"
" Filter: ((conversion_date >= '2005-06-07'::date)
AND (conversion_date <= '2005-08-17'::date))"
I dont know why system is doing "Seq scan" now.
Thanks
asif ali
..3120.324 rows=55717
loops=1)"
" -> Seq Scan on conversion_table c
(cost=0.00..27336.12 rows=4986 width=16) (actual
time=0.047..1352.212 rows=885493 loops=1)"
" Filter: ((conversion_date >=
'2005-06-07'::date) AND (conversion_date <=
'2005-08-17&#
rows=870730 width=37) (actual
time=0.007..1520.788 rows=885493 loops=1)"
" Filter: ((conversion_date >=
'2005-06-07'::date) AND (conversion_date <=
'2005-08-17'::date))"
"Total runtime: 14859.291 ms"
--- Michael Fuhr <[E
"Total runtime: 5463.764 ms"
Thanks a lot
--- Michael Fuhr <[EMAIL PROTECTED]> wrote:
> On Mon, Aug 29, 2005 at 11:07:17AM -0700, asif ali
> wrote:
> > The database is on the same system.
> > What I am doing is only "VACUUM analyze
> > conversion
"product" table but It did not work.
I checked the file size of these two tables.
"product" table's file size is "32mb" and
"product_temp" table's file size is "72k".
So, it seems that "VACUUM FULL" is not doing an
Thanks for the prompt reply...
Here is the output of "VACUUM FULL VERBOSE"
The postgres version is "8.0.3".
Thanks
asif ali
icrossing inc
INFO: vacuuming "public.product_table"
INFO: "product_table": found 0 removable, 139178 nonremovable row
Thanks Everybody for helping me out.
I checked "pg_stat_activity"/pg_locks, but do not see any activity on the
table.
How to find a old running transaction...
I saw this link, but it did not help..
http://archives.postgresql.org/pgsql-hackers/2005-02/msg00760.php
Thanks
Thanks Scott,
It worked!!!
We killed an old idle running transaction, now everything is fine..
Thanks Again
asif ali
icrossing inc
Scott Marlowe <[EMAIL PROTECTED]> wrote: On Wed, 2006-12-06 at 15:53, asif ali
wrote:
> Thanks Everybody for helping me out.
> I checked "
Arnaud,
Have you run "ANALYZE" on the table after creating index?
Also make sure that "#effective_cache_size" is set properly. A higher
value makes it more likely to use index scans.
Thanks
asif ali
Arnaud Lesauvage <[EMAIL PROTECTED]> wrote: Ragnar a éc
