From: | Rod Taylor <rbt(at)rbt(dot)ca> |
---|---|
To: | mallah(at)trade-india(dot)com |
Cc: | pgsql-admin(at)postgresql(dot)org, pgsql-performance(at)postgresql(dot)org |
Subject: | Re: [pgsql-performance] Is dump-reload the only cure? |
Date: | 2002-11-01 14:07:41 |
Message-ID: | 1036159661.5794.0.camel@jester |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-admin pgsql-performance |
See Paragraph 2 of the description section:
http://www.postgresql.org/idocs/index.php?sql-explain.html
In the above is a good explanation of 'cost'. Rows is the number of
rows estimated to be returned, and width is the expected number of
columns it needs to deal with at that point.
On Fri, 2002-11-01 at 08:03, mallah(at)trade-india(dot)com wrote:
>
> Hi Rod ,
>
> Does it means that index scan is used for less frequenlty occuring data?
> yes my table was not clustered.
>
> can u tell me what does 0.00..6788.24 and rows and width means?
>
> in explain out put cost=0.00..6788.24 rows=30001 width=4
>
>
> I have one more table where i face the similar problem , i have not dump - reloaded
> it yet , will post again if i face the problem.
>
>
> thanks
>
> Regds
> Mallah.
>
>
> > On Fri, 2002-11-01 at 06:15, mallah(at)trade-india(dot)com wrote:
> >
> >
> > Looks like a borderline case. See the costs of the index scan and sequential scan are very
> > similar. Since 499 covers nearly 1 in 10 tuples, it's likely found on nearly every page. This
> > should make a sequential scan much cheaper.
> >
> > However, if the data is clumped together (not distributed throughout the table) than an index
> > scan may be preferable. So... CLUSTER may be useful to you.
> >
> > In the future please 'explain analyze' the queries you're looking at to see actual costs as
> > compared to the estimated cost.
> >
> >
> >> 499 | 25010
> >> 501 | 3318
> >>
> >>
> >> before dump reload:
> >> tradein_clients=# VACUUM VERBOSE ANALYZE email_bank_mailing_lists; NOTICE: --Relation
> >> email_bank_mailing_lists--
> >> NOTICE: Pages 3583: Changed 0, Empty 0; Tup 256419: Vac 0, Keep 0, UnUsed 44822.
> >> Total CPU 0.24s/0.04u sec elapsed 0.30 sec.
> >> NOTICE: Analyzing email_bank_mailing_lists
> >> VACUUM
> >> tradein_clients=# explain SELECT count( email_id ) from email_bank_mailing_lists where
> >> query_id=499;NOTICE: QUERY PLAN:
> >>
> >> Aggregate (cost=6863.24..6863.24 rows=1 width=4)
> >> -> Seq Scan on email_bank_mailing_lists (cost=0.00..6788.24 rows=30001 width=4)
> >>
> >> EXPLAIN
> >
> > --
> > Rod Taylor
>
>
>
> -----------------------------------------
> Get your free web based email at trade-india.com.
> "India's Leading B2B eMarketplace.!"
> http://www.trade-india.com/
>
>
>
> ---------------------------(end of broadcast)---------------------------
> TIP 6: Have you searched our list archives?
>
> http://archives.postgresql.org
>
--
Rod Taylor
From | Date | Subject | |
---|---|---|---|
Next Message | Rod Taylor | 2002-11-01 14:11:03 | Re: [pgsql-performance] Is dump-reload the only cure? |
Previous Message | mallah | 2002-11-01 13:15:22 | Re: [pgsql-performance] Is dump-reload the only cure? |
From | Date | Subject | |
---|---|---|---|
Next Message | Rod Taylor | 2002-11-01 14:11:03 | Re: [pgsql-performance] Is dump-reload the only cure? |
Previous Message | mallah | 2002-11-01 13:15:22 | Re: [pgsql-performance] Is dump-reload the only cure? |