Re: Transaction progress
От | Manfred Koizar |
---|---|
Тема | Re: Transaction progress |
Дата | |
Msg-id | k24m2voenqu62ifurhevhl4ogp4smbi393@4ax.com обсуждение исходный текст |
Ответ на | Transaction progress (Pablo Yaggi <pyaggi@aulamagna.com.ar>) |
Ответы |
Re: Transaction progress
|
Список | pgsql-general |
On Sun, 19 Jan 2003 14:53:49 -0300, Pablo Yaggi <pyaggi@aulamagna.com.ar> wrote: >if not, can I estimate the time from the explain result ? how ? >this is the explain result about the query I'm running: > >Hash Join (cost=100347487.59..145240934.03 rows=26 width=60) > -> Index Scan using inars_rectificaciones_inx on inars_rectificaciones b2 > (cost=0.00..37839140.62 rows=9546466 width=34) ^^^^^^^ ^^ (c) (d) > -> Hash (cost=100347379.07..100347379.07 rows=43407 width=26) > -> Seq Scan on inars_nocontrib_perm1 > (cost=100000000.00..100347379.07 rows=43407 width=26) ^^^^^^^^^^^^ ^^^^^^ (a) (b) The end result of explain, 145240934.03, basically tells us that you have SET enable_seqscan = OFF (a). (b) looks a bit strange. Does inars_nocontrib_perm1 have 300000 pages but only 43407 tuples? If so, you should VACUUM more often. Anyway this seq scan contributes only a small fraction to the overall cost. (c) There are almost 10M rows in inars_rectificaciones, the width of which is at least 34 (d). Counting for overhead and columns not used by your statement, let's guess 80 bytes per tuple (might be more). This gives at least 800MB for the whole relation. Assuming that your physical memory is much less than this and the index inars_rectificaciones_inx doesn't retrieve tuples in physical order, you need one random page read per tuple. So your question boils down to how long it takes to do 10M random reads on your hardware. I have to guess again: 4ms seek, 4ms latency. Ignoring CPU and transfer times we get 8ms per page access or 80000 seconds (more than 22 hours) for the query on average PC hardware. This could be much more, if your disk is fragmented or slow or both ... Next time you run that query SET enable_seqscan = ON; this should cut down execution time to way below one hour. YMMV. Servus Manfred
В списке pgsql-general по дате отправления: