Bad performace of a query
I have this query:
SELECT DISTINCT isbn, CURRENT_TIMESTAMP, 1
FROM librosdisponibilidadtemp
WHERE proceso = ai_proceso
AND gen_isbn_pais(isbn) IN (SELECT pais FROM raizpaises)
AND NOT EXISTS
( SELECT isbn
FROM libros
WHERE isbn = librosdisponibilidadtemp.isbn)
AND NOT EXISTS
( SELECT isbn
FROM isbns_a_descubrir
WHERE isbn = librosdisponibilidadtemp.isbn);
and the plan execution is
Unique (cost=133558107.45..133558128.13 rows=414 width=21) (actual time=
790552.899..790553.098 rows=9 loops=1)
-> Sort (cost=133558107.45..133558112.62 rows=2068 width=21) (actual
time=790552.882..790552.944 rows=9 loops=1)
Sort Key: isbn, now(), 1
-> Index Scan using librosdisponibilidadtemp_idx_proceso on
librosdisponibilidadtemp (cost=1.01..133557993.56 rows=2068 width=21)
(actual time=5722.607..790552.588 rows=9 loops=1)
Index Cond: (proceso = 28465)
Filter: ((hashed subplan) AND (NOT (subplan)) AND (NOT
(subplan)))
SubPlan
-> Seq Scan on isbns_a_descubrir
(cost=0.00..8067.91rows=1 width=21) (actual time=
30.044..30.044 rows=1 loops=2025)
Filter: ((isbn)::bpchar = $1)
-> Index Scan using "libros_idx_ISBN" on libros (cost=
0.00..5.95 rows=1 width=21) (actual time=12.938..12.938 rows=1 loops=50512)
Index Cond: (isbn = $1)
-> Seq Scan on raizpaises (cost=0.00..1.01 rows=1
width=10) (actual time=0.764..0.871 rows=1 loops=1)
Total runtime: 790553.561 ms
The libros table has 1200000 regs.
The isbns_a_descubrir table has 300000 regs.
The librosdisponibilidadtemp table has 50000 regs.
does anybody can explain me, why using index
ibrosdisponibilidadtemp_idx_proceso is so slow and the others conditions are
good enough
Thanks everybody
<!DOCTYPE html PUBLIC "-//W3C//DTD HTML 4.01 Transitional//EN">
<html>
<head>
<meta content="text/html;charset=windows-1251"
http-equiv="Content-Type">
<title></title>
</head>
<body alink="#ee0000" bgcolor="#ffffff" link="#0000ee" text="#000000"
vlink="#551a8b">
Hi,<br>
<br>
The index doesn't cost you so much, seq SEQ Scan actully does:<br>
<font color="#ff0000"> Seq Scan on isbns_a_descubrirпїЅ
(cost=0.00..8067.91 rows=1 width=21) (actual time=30.044..30.044 rows=1
loops=2025)</font><br>
<br>
This seq scan is called once for every row of librosdisponibilidadtemp
which passes the WHERE condition.<br>
So Here "<font color="#ff0000">Index Scan using
librosdisponibilidadtemp_idx_proceso on librosdisponibilidadtempпїЅ
(cost=
1.01..133557993.56 rows=2068 width=21) (actual
time=5722.607..790552.588 rows=9 loops=1)"<font color="#000000"> it
says how much it will cost you to calculate the upper seq scan and the
seq scan on <font color="#ff0000">(</font></font>Seq Scan on
raizpaises) <font color="#000000">and the index scan on </font></font>libros.<br>
<br>
I suggest you to create index on table <b>isbns_a_descubrir </b>over
column isbn. This will hurry the query.<br>
And use join instead of IN for table raizpaises. This should also save
some time.<br>
<br>
Regards,<br>
пїЅпїЅ Kaloyan Iliev<br>
<br>
<blockquote
cite="midbd8b58a40702270528i7c395029v4a8bf3eb442bc8c9@mail.gmail.com"
type="cite">ave this query:<br>
<br>
SELECT DISTINCT isbn, CURRENT_TIMESTAMP, 1<br>
пїЅпїЅпїЅпїЅпїЅпїЅпїЅпїЅпїЅпїЅпїЅпїЅпїЅ FROM librosdisponibilidadtemp<br>
пїЅпїЅпїЅпїЅпїЅпїЅпїЅпїЅпїЅпїЅпїЅпїЅ WHERE proceso = ai_proceso<br>
пїЅпїЅпїЅпїЅпїЅпїЅпїЅпїЅпїЅпїЅпїЅпїЅпїЅпїЅ AND gen_isbn_pais(isbn) IN (SELECT pais FROM raizpaises)
<br>
пїЅпїЅпїЅпїЅпїЅпїЅпїЅпїЅпїЅпїЅпїЅпїЅпїЅпїЅ AND NOT EXISTS<br>
пїЅпїЅпїЅпїЅпїЅпїЅпїЅпїЅпїЅпїЅпїЅпїЅпїЅпїЅпїЅпїЅпїЅпїЅ ( SELECT isbn<br>
пїЅпїЅпїЅпїЅпїЅпїЅпїЅпїЅпїЅпїЅпїЅпїЅпїЅпїЅпїЅпїЅпїЅпїЅпїЅпїЅпїЅпїЅ FROM libros<br>
пїЅпїЅпїЅпїЅпїЅпїЅпїЅпїЅпїЅпїЅпїЅпїЅпїЅпїЅпїЅпїЅпїЅпїЅпїЅпїЅпїЅ WHERE isbn = librosdisponibilidadtemp.isbn)<br>
пїЅпїЅпїЅпїЅпїЅпїЅпїЅпїЅпїЅпїЅпїЅпїЅпїЅпїЅ AND NOT EXISTS<br>
пїЅпїЅпїЅпїЅпїЅпїЅпїЅпїЅпїЅпїЅпїЅпїЅпїЅпїЅпїЅпїЅпїЅпїЅ ( SELECT isbn
<br>
пїЅпїЅпїЅпїЅпїЅпїЅпїЅпїЅпїЅпїЅпїЅпїЅпїЅпїЅпїЅпїЅпїЅпїЅпїЅпїЅпїЅпїЅ FROM isbns_a_descubrir<br>
пїЅпїЅпїЅпїЅпїЅпїЅпїЅпїЅпїЅпїЅпїЅпїЅпїЅпїЅпїЅпїЅпїЅпїЅпїЅпїЅпїЅ WHERE isbn = librosdisponibilidadtemp.isbn);<br>
<br>
and the plan execution is<br>
UniqueпїЅ (cost=133558107.45..133558128.13 rows=414 width=21) (actual
time=
790552.899..790553.098 rows=9 loops=1)<br>
пїЅ ->пїЅ SortпїЅ (cost=133558107.45..133558112.62 rows=2068 width=21)
(actual time=790552.882..790552.944 rows=9 loops=1)<br>
пїЅпїЅпїЅпїЅпїЅпїЅпїЅ Sort Key: isbn, now(), 1<br>
пїЅпїЅпїЅпїЅпїЅпїЅпїЅ ->пїЅ Index Scan using librosdisponibilidadtemp_idx_proceso on
librosdisponibilidadtempпїЅ (cost=
1.01..133557993.56 rows=2068 width=21) (actual
time=5722.607..790552.588 rows=9 loops=1)<br>
пїЅпїЅпїЅпїЅпїЅпїЅпїЅпїЅпїЅпїЅпїЅпїЅпїЅ Index Cond: (proceso = 28465)<br>
пїЅпїЅпїЅпїЅпїЅпїЅпїЅпїЅпїЅпїЅпїЅпїЅпїЅ Filter: ((hashed subplan) AND (NOT (subplan)) AND (NOT
(subplan)))<br>
пїЅпїЅпїЅпїЅпїЅпїЅпїЅпїЅпїЅпїЅпїЅпїЅпїЅ SubPlan<br>
пїЅпїЅпїЅпїЅпїЅпїЅпїЅпїЅпїЅпїЅпїЅпїЅпїЅпїЅпїЅ ->пїЅ Seq Scan on isbns_a_descubrirпїЅ
(cost=0.00..8067.91 rows=1 width=21) (actual time=30.044..30.044 rows=1
loops=2025)<br>
пїЅпїЅпїЅпїЅпїЅпїЅпїЅпїЅпїЅпїЅпїЅпїЅпїЅпїЅпїЅпїЅпїЅпїЅпїЅпїЅпїЅ Filter: ((isbn)::bpchar = $1)<br>
пїЅпїЅпїЅпїЅпїЅпїЅпїЅпїЅпїЅпїЅпїЅпїЅпїЅпїЅпїЅ ->пїЅ Index Scan using "libros_idx_ISBN" on librosпїЅ
(cost=0.00..5.95 rows=1 width=21) (actual time=12.938..12.938 rows=1
loops=50512)<br>
пїЅпїЅпїЅпїЅпїЅпїЅпїЅпїЅпїЅпїЅпїЅпїЅпїЅпїЅпїЅпїЅпїЅпїЅпїЅпїЅпїЅ Index Cond: (isbn = $1)<br>
пїЅпїЅпїЅпїЅпїЅпїЅпїЅпїЅпїЅпїЅпїЅпїЅпїЅпїЅпїЅ ->пїЅ Seq Scan on raizpaisesпїЅ (cost=
0.00..1.01 rows=1 width=10) (actual time=0.764..0.871 rows=1 loops=1)<br>
Total runtime: 790553.561 ms<br>
<br>
The libros table has 1200000 regs.<br>
The isbns_a_descubrir table has 300000 regs.<br>
The librosdisponibilidadtemp table has 50000 regs. <br>
<br>
does anybody can explain me, why using index
ibrosdisponibilidadtemp_idx_proceso is so slow and the others
conditions are good enough<br>
Thanks everybody<br>
<br>
<br>
</blockquote>
<br>
</body>
</html>
<!DOCTYPE html PUBLIC "-//W3C//DTD HTML 4.01 Transitional//EN">
<html>
<head>
<meta content="text/html;charset=windows-1251"
http-equiv="Content-Type">
<title></title>
</head>
<body alink="#ee0000" bgcolor="#ffffff" link="#0000ee" text="#000000"
vlink="#551a8b">
<meta content="text/html;charset=windows-1251" http-equiv="Content-Type">
<title></title>
Hi,<br>
<br>
The index doesn't cost you so much, seq SEQ Scan actully does:<br>
<font color="#ff0000"> Seq Scan on isbns_a_descubrirпїЅ
(cost=0.00..8067.91 rows=1 width=21) (actual time=30.044..30.044 rows=1
loops=2025)</font><br>
<br>
This seq scan is called once for every row of librosdisponibilidadtemp
which passes the WHERE condition.<br>
So Here "<font color="#ff0000">Index Scan using
librosdisponibilidadtemp_idx_proceso on librosdisponibilidadtempпїЅ
(cost=
1.01..133557993.56 rows=2068 width=21) (actual
time=5722.607..790552.588 rows=9 loops=1)"<font color="#000000"> it
says how much it will cost you to calculate the upper seq scan and the
seq scan on <font color="#ff0000">(</font></font>Seq Scan on
raizpaises) <font color="#000000">and the index scan on </font></font>libros.<br>
<br>
I suggest you to create index on table <b>isbns_a_descubrir </b>over
column isbn. This will hurry the query.<br>
And use join instead of IN for table raizpaises. This should also save
some time.<br>
<br>
Regards,<br>
пїЅпїЅ Kaloyan Iliev<br>
<br>
<blockquote
cite="midbd8b58a40702270528i7c395029v4a8bf3eb442bc8c9@mail.gmail.com"
type="cite">ave this query:<br>
<br>
SELECT DISTINCT isbn, CURRENT_TIMESTAMP, 1<br>
пїЅпїЅпїЅпїЅпїЅпїЅпїЅпїЅпїЅпїЅпїЅпїЅпїЅ FROM librosdisponibilidadtemp<br>
пїЅпїЅпїЅпїЅпїЅпїЅпїЅпїЅпїЅпїЅпїЅпїЅ WHERE proceso = ai_proceso<br>
пїЅпїЅпїЅпїЅпїЅпїЅпїЅпїЅпїЅпїЅпїЅпїЅпїЅпїЅ AND gen_isbn_pais(isbn) IN (SELECT pais FROM raizpaises)
<br>
пїЅпїЅпїЅпїЅпїЅпїЅпїЅпїЅпїЅпїЅпїЅпїЅпїЅпїЅ AND NOT EXISTS<br>
пїЅпїЅпїЅпїЅпїЅпїЅпїЅпїЅпїЅпїЅпїЅпїЅпїЅпїЅпїЅпїЅпїЅпїЅ ( SELECT isbn<br>
пїЅпїЅпїЅпїЅпїЅпїЅпїЅпїЅпїЅпїЅпїЅпїЅпїЅпїЅпїЅпїЅпїЅпїЅпїЅпїЅпїЅпїЅ FROM libros<br>
пїЅпїЅпїЅпїЅпїЅпїЅпїЅпїЅпїЅпїЅпїЅпїЅпїЅпїЅпїЅпїЅпїЅпїЅпїЅпїЅпїЅ WHERE isbn = librosdisponibilidadtemp.isbn)<br>
пїЅпїЅпїЅпїЅпїЅпїЅпїЅпїЅпїЅпїЅпїЅпїЅпїЅпїЅ AND NOT EXISTS<br>
пїЅпїЅпїЅпїЅпїЅпїЅпїЅпїЅпїЅпїЅпїЅпїЅпїЅпїЅпїЅпїЅпїЅпїЅ ( SELECT isbn <br>
пїЅпїЅпїЅпїЅпїЅпїЅпїЅпїЅпїЅпїЅпїЅпїЅпїЅпїЅпїЅпїЅпїЅпїЅпїЅпїЅпїЅпїЅ FROM isbns_a_descubrir<br>
пїЅпїЅпїЅпїЅпїЅпїЅпїЅпїЅпїЅпїЅпїЅпїЅпїЅпїЅпїЅпїЅпїЅпїЅпїЅпїЅпїЅ WHERE isbn = librosdisponibilidadtemp.isbn);<br>
<br>
and the plan execution is<br>
UniqueпїЅ (cost=133558107.45..133558128.13 rows=414 width=21) (actual
time=
790552.899..790553.098 rows=9 loops=1)<br>
пїЅ ->пїЅ SortпїЅ (cost=133558107.45..133558112.62 rows=2068 width=21)
(actual time=790552.882..790552.944 rows=9 loops=1)<br>
пїЅпїЅпїЅпїЅпїЅпїЅпїЅ Sort Key: isbn, now(), 1<br>
пїЅпїЅпїЅпїЅпїЅпїЅпїЅ ->пїЅ Index Scan using librosdisponibilidadtemp_idx_proceso on
librosdisponibilidadtempпїЅ (cost=
1.01..133557993.56 rows=2068 width=21) (actual
time=5722.607..790552.588 rows=9 loops=1)<br>
пїЅпїЅпїЅпїЅпїЅпїЅпїЅпїЅпїЅпїЅпїЅпїЅпїЅ Index Cond: (proceso = 28465)<br>
пїЅпїЅпїЅпїЅпїЅпїЅпїЅпїЅпїЅпїЅпїЅпїЅпїЅ Filter: ((hashed subplan) AND (NOT (subplan)) AND (NOT
(subplan)))<br>
пїЅпїЅпїЅпїЅпїЅпїЅпїЅпїЅпїЅпїЅпїЅпїЅпїЅ SubPlan<br>
пїЅпїЅпїЅпїЅпїЅпїЅпїЅпїЅпїЅпїЅпїЅпїЅпїЅпїЅпїЅ ->пїЅ Seq Scan on isbns_a_descubrirпїЅ
(cost=0.00..8067.91 rows=1 width=21) (actual time=30.044..30.044 rows=1
loops=2025)<br>
пїЅпїЅпїЅпїЅпїЅпїЅпїЅпїЅпїЅпїЅпїЅпїЅпїЅпїЅпїЅпїЅпїЅпїЅпїЅпїЅпїЅ Filter: ((isbn)::bpchar = $1)<br>
пїЅпїЅпїЅпїЅпїЅпїЅпїЅпїЅпїЅпїЅпїЅпїЅпїЅпїЅпїЅ ->пїЅ Index Scan using "libros_idx_ISBN" on librosпїЅ
(cost=0.00..5.95 rows=1 width=21) (actual time=12.938..12.938 rows=1
loops=50512)<br>
пїЅпїЅпїЅпїЅпїЅпїЅпїЅпїЅпїЅпїЅпїЅпїЅпїЅпїЅпїЅпїЅпїЅпїЅпїЅпїЅпїЅ Index Cond: (isbn = $1)<br>
пїЅпїЅпїЅпїЅпїЅпїЅпїЅпїЅпїЅпїЅпїЅпїЅпїЅпїЅпїЅ ->пїЅ Seq Scan on raizpaisesпїЅ (cost=
0.00..1.01 rows=1 width=10) (actual time=0.764..0.871 rows=1 loops=1)<br>
Total runtime: 790553.561 ms<br>
<br>
The libros table has 1200000 regs.<br>
The isbns_a_descubrir table has 300000 regs.<br>
The librosdisponibilidadtemp table has 50000 regs. <br>
<br>
does anybody can explain me, why using index
ibrosdisponibilidadtemp_idx_proceso is so slow and the others
conditions are good enough<br>
Thanks everybody<br>
<br>
<br>
</blockquote>
<br>
</body>
</html>
<!DOCTYPE html PUBLIC "-//W3C//DTD HTML 4.01 Transitional//EN">
<html>
<head>
<meta content="text/html;charset=windows-1251"
http-equiv="Content-Type">
<title></title>
</head>
<body alink="#ee0000" bgcolor="#ffffff" link="#0000ee" text="#000000"
vlink="#551a8b">
<meta content="text/html;charset=windows-1251" http-equiv="Content-Type">
<title></title>
<meta content="text/html;charset=windows-1251" http-equiv="Content-Type">
<title></title>
Hi,<br>
<br>
The index doesn't cost you so much, seq SEQ Scan actully does:<br>
<font color="#ff0000"> Seq Scan on isbns_a_descubrirпїЅ
(cost=0.00..8067.91 rows=1 width=21) (actual time=30.044..30.044 rows=1
loops=2025)</font><br>
<br>
This seq scan is called once for every row of librosdisponibilidadtemp
which passes the WHERE condition.<br>
So Here "<font color="#ff0000">Index Scan using
librosdisponibilidadtemp_idx_proceso on librosdisponibilidadtempпїЅ
(cost=
1.01..133557993.56 rows=2068 width=21) (actual
time=5722.607..790552.588 rows=9 loops=1)"<font color="#000000"> it
says how much it will cost you to calculate the upper seq scan and the
seq scan on <font color="#ff0000">(</font></font>Seq Scan on
raizpaises) <font color="#000000">and the index scan on </font></font>libros.<br>
<br>
I suggest you to create index on table <b>isbns_a_descubrir </b>over
column isbn. This will hurry the query.<br>
And use join instead of IN for table raizpaises. This should also save
some time.<br>
<br>
Regards,<br>
пїЅпїЅ Kaloyan Iliev<br>
<br>
<blockquote
cite="midbd8b58a40702270528i7c395029v4a8bf3eb442bc8c9@mail.gmail.com"
type="cite">ave this query:<br>
<br>
SELECT DISTINCT isbn, CURRENT_TIMESTAMP, 1<br>
пїЅпїЅпїЅпїЅпїЅпїЅпїЅпїЅпїЅпїЅпїЅпїЅпїЅ FROM librosdisponibilidadtemp<br>
пїЅпїЅпїЅпїЅпїЅпїЅпїЅпїЅпїЅпїЅпїЅпїЅ WHERE proceso = ai_proceso<br>
пїЅпїЅпїЅпїЅпїЅпїЅпїЅпїЅпїЅпїЅпїЅпїЅпїЅпїЅ AND gen_isbn_pais(isbn) IN (SELECT pais FROM raizpaises)
<br>
пїЅпїЅпїЅпїЅпїЅпїЅпїЅпїЅпїЅпїЅпїЅпїЅпїЅпїЅ AND NOT EXISTS<br>
пїЅпїЅпїЅпїЅпїЅпїЅпїЅпїЅпїЅпїЅпїЅпїЅпїЅпїЅпїЅпїЅпїЅпїЅ ( SELECT isbn<br>
пїЅпїЅпїЅпїЅпїЅпїЅпїЅпїЅпїЅпїЅпїЅпїЅпїЅпїЅпїЅпїЅпїЅпїЅпїЅпїЅпїЅпїЅ FROM libros<br>
пїЅпїЅпїЅпїЅпїЅпїЅпїЅпїЅпїЅпїЅпїЅпїЅпїЅпїЅпїЅпїЅпїЅпїЅпїЅпїЅпїЅ WHERE isbn = librosdisponibilidadtemp.isbn)<br>
пїЅпїЅпїЅпїЅпїЅпїЅпїЅпїЅпїЅпїЅпїЅпїЅпїЅпїЅ AND NOT EXISTS<br>
пїЅпїЅпїЅпїЅпїЅпїЅпїЅпїЅпїЅпїЅпїЅпїЅпїЅпїЅпїЅпїЅпїЅпїЅ ( SELECT isbn <br>
пїЅпїЅпїЅпїЅпїЅпїЅпїЅпїЅпїЅпїЅпїЅпїЅпїЅпїЅпїЅпїЅпїЅпїЅпїЅпїЅпїЅпїЅ FROM isbns_a_descubrir<br>
пїЅпїЅпїЅпїЅпїЅпїЅпїЅпїЅпїЅпїЅпїЅпїЅпїЅпїЅпїЅпїЅпїЅпїЅпїЅпїЅпїЅ WHERE isbn = librosdisponibilidadtemp.isbn);<br>
<br>
and the plan execution is<br>
UniqueпїЅ (cost=133558107.45..133558128.13 rows=414 width=21) (actual
time=
790552.899..790553.098 rows=9 loops=1)<br>
пїЅ ->пїЅ SortпїЅ (cost=133558107.45..133558112.62 rows=2068 width=21)
(actual time=790552.882..790552.944 rows=9 loops=1)<br>
пїЅпїЅпїЅпїЅпїЅпїЅпїЅ Sort Key: isbn, now(), 1<br>
пїЅпїЅпїЅпїЅпїЅпїЅпїЅ ->пїЅ Index Scan using librosdisponibilidadtemp_idx_proceso on
librosdisponibilidadtempпїЅ (cost=
1.01..133557993.56 rows=2068 width=21) (actual
time=5722.607..790552.588 rows=9 loops=1)<br>
пїЅпїЅпїЅпїЅпїЅпїЅпїЅпїЅпїЅпїЅпїЅпїЅпїЅ Index Cond: (proceso = 28465)<br>
пїЅпїЅпїЅпїЅпїЅпїЅпїЅпїЅпїЅпїЅпїЅпїЅпїЅ Filter: ((hashed subplan) AND (NOT (subplan)) AND (NOT
(subplan)))<br>
пїЅпїЅпїЅпїЅпїЅпїЅпїЅпїЅпїЅпїЅпїЅпїЅпїЅ SubPlan<br>
пїЅпїЅпїЅпїЅпїЅпїЅпїЅпїЅпїЅпїЅпїЅпїЅпїЅпїЅпїЅ ->пїЅ Seq Scan on isbns_a_descubrirпїЅ
(cost=0.00..8067.91 rows=1 width=21) (actual time=30.044..30.044 rows=1
loops=2025)<br>
пїЅпїЅпїЅпїЅпїЅпїЅпїЅпїЅпїЅпїЅпїЅпїЅпїЅпїЅпїЅпїЅпїЅпїЅпїЅпїЅпїЅ Filter: ((isbn)::bpchar = $1)<br>
пїЅпїЅпїЅпїЅпїЅпїЅпїЅпїЅпїЅпїЅпїЅпїЅпїЅпїЅпїЅ ->пїЅ Index Scan using "libros_idx_ISBN" on librosпїЅ
(cost=0.00..5.95 rows=1 width=21) (actual time=12.938..12.938 rows=1
loops=50512)<br>
пїЅпїЅпїЅпїЅпїЅпїЅпїЅпїЅпїЅпїЅпїЅпїЅпїЅпїЅпїЅпїЅпїЅпїЅпїЅпїЅпїЅ Index Cond: (isbn = $1)<br>
пїЅпїЅпїЅпїЅпїЅпїЅпїЅпїЅпїЅпїЅпїЅпїЅпїЅпїЅпїЅ ->пїЅ Seq Scan on raizpaisesпїЅ (cost=
0.00..1.01 rows=1 width=10) (actual time=0.764..0.871 rows=1 loops=1)<br>
Total runtime: 790553.561 ms<br>
<br>
The libros table has 1200000 regs.<br>
The isbns_a_descubrir table has 300000 regs.<br>
The librosdisponibilidadtemp table has 50000 regs. <br>
<br>
does anybody can explain me, why using index
ibrosdisponibilidadtemp_idx_proceso is so slow and the others
conditions are good enough<br>
Thanks everybody<br>
<br>
<br>
</blockquote>
<br>
</body>
</html>