使用LIKE索引 [英] index with LIKE
问题描述
大家好，
我的master-db-server上的
我正在运行postgres 7.4.1，
我有两台运行postgres的奴隶服务器7.4.2
在主服务器上运行以下查询（7.4.1）提供：
解释分析select * from foo，其中bar喜欢''0101％''和foobar喜欢
''top％'';
索引在foo上使用foo_foobar_idx扫描（费用...）
索引条件：（（foobar> =''top :: text）和（firma<''toq'':: text））
过滤:(（bar ~~''0101％'':: text）和（firma ~~''top％'':: text））
总运行时间：1.519 ms
两个从站上的相同查询（7.4.2）（从主镜像，相同的
表结构等）产生：
Seq扫描foo（成本....）
过滤:(（吧~~''0101％'':: text）AND（foobar~ 〜''top％'':: text））
总运行时间：722.331 ms
是否有这样的广告在7.4.1到7.4.2中的推理？
我不能接受722毫秒的延迟，我不明白为什么
没有使用索引。
你有什么想法吗？我已多次运行VACUUM ANALYZE，并且
REINDEX TABLE foo甚至
DROPped并重新编译索引。没有帮助。
BTW如果我跑：
解释分析select * from foo where bar like''0101％''和
foobar> =''top'':: text和foobar<''toq'':: text;
索引被利用，因为它应该是
任何暗示赞赏，
谢谢
-
Mit freundlichem Gru ？
Henrik Steffen
Gesch？ftsführer
顶级概念Internetmarketing GmbH
Am Steinkamp 7 - D-21684 Stade - 德国
-------------------------------- ------------------------
http://www.topconcepts.de 电话。 +49 1805 9977 501 *
邮件： st*****@topconcepts.de 传真。 +49 1805 9977 502 *
------------------------------------ --------------------
SMS Versand ab 9.9分： http://sms-gw.topconcepts.de
--------------- -----------------------------------------
Handelsregister ：AG Stade HRB 5811 - UstId：DE 213645563
-------------------------------- ------------------------
*）EUR 0,12 / Min。 （CNS24）
---------------------------（播出结束）--- ------------------------
提示5：您查看了我们广泛的常见问题解答吗？
http://www.postgresql.org/docs/faqs/FAQ。 html
hello all,
on my master-db-server i''m running postgres 7.4.1,
and I have got two slave-servers running postgres 7.4.2
running the following query on the master-server (7.4.1) delivers:
explain analyze select * from foo where bar like ''0101%'' and foobar like
''top%'';
Index Scan using foo_foobar_idx on foo (cost...)
Index Cond: ((foobar>=''top::text) and (firma < ''toq''::text))
Filter: ((bar ~~ ''0101%''::text) and (firma ~~ ''top%''::text))
Total runtime: 1.519 ms
the same query on both slaves (7.4.2)(mirrored from master, same
structure of table etc.) yields:
Seq Scan on foo (cost ....)
Filter: ((bar ~~ ''0101%''::text) AND (foobar ~~ ''top%''::text))
Total runtime: 722.331 ms
Is there such a difference in 7.4.1 to 7.4.2 ?
A retardation of 722 ms is not acceptable for me, and I don''t see why
the indexes are not used.
Do you have an idea? I have run VACUUM ANALYZE several times, and
REINDEX TABLE foo and even
DROPped and reCREATEd the index. Didn''t help.
BTW if I run:
explain analyze select * from foo where bar like ''0101%'' and
foobar>=''top''::text and foobar<''toq''::text;
the index is utilized as it is supposed to
Any hint appreciated,
thank you
--
Mit freundlichem Gru?
Henrik Steffen
Gesch?ftsführer
top concepts Internetmarketing GmbH
Am Steinkamp 7 - D-21684 Stade - Germany
--------------------------------------------------------
http://www.topconcepts.de Tel. +49 1805 9977 501*
mail: st*****@topconcepts.de Fax. +49 1805 9977 502*
--------------------------------------------------------
SMS Versand ab 9.9 Cent: http://sms-gw.topconcepts.de
--------------------------------------------------------
Handelsregister: AG Stade HRB 5811 - UstId: DE 213645563
--------------------------------------------------------
*) EUR 0,12/Min. (CNS24)
---------------------------(end of broadcast)---------------------------
TIP 5: Have you checked our extensive FAQ?
http://www.postgresql.org/docs/faqs/FAQ.html
推荐答案
2004年6月9日星期三上午9：00：31 + 0200，Henrik Steffen写道：
On Wed, Jun 09, 2004 at 09:00:31AM +0200, Henrik Steffen wrote:
大家好，
我的master-db-server我正在运行postgres 7.4.1，
我有两个奴隶 - 运行postgres的服务器7.4.2
< snip>
在7.4.1到7.4.2之间是否存在这样的差异？
<延迟722毫秒对我来说是不可接受的，我不明白为什么不使用索引。
你有什么想法吗？我已多次运行VACUUM ANALYZE，并且REINDEX TABLE foo甚至
DROPped和reCREATEd索引。没有帮助。
经典问题是数据库的编码。除了C之外还有其他什么比b和b更不喜欢使用索引。
另外，你对两者进行了真空分析，对吧？
希望这会有所帮助，
-
Martijn van Oosterhout< kl ***** @ svana.org> http://svana.org/kleptog/ 专利。 ñ。天才是5％的灵感和95％的汗水。专利是一种工具，用于完成5％的工作，然后坐在那里等待某人其他95％，这样你就可以起诉他们。
hello all,
on my master-db-server i''m running postgres 7.4.1,
and I have got two slave-servers running postgres 7.4.2
<snip>
Is there such a difference in 7.4.1 to 7.4.2 ?
A retardation of 722 ms is not acceptable for me, and I don''t see why
the indexes are not used.
Do you have an idea? I have run VACUUM ANALYZE several times, and
REINDEX TABLE foo and even
DROPped and reCREATEd the index. Didn''t help.
The classic issue is what encoding are the databases. Anything other
than C and like won''t use indexes.
Also, you did a vacuum analyze on both, right?
Hope this helps,
--
Martijn van Oosterhout <kl*****@svana.org> http://svana.org/kleptog/ Patent. n. Genius is 5% inspiration and 95% perspiration. A patent is a
tool for doing 5% of the work and then sitting around waiting for someone
else to do the other 95% so you can sue them.
----- BEGIN PGP SIGNATURE -----
版本：GnuPG v1.0.6（GNU / Linux）
评论：有关信息请参阅 http://www.gnupg.org
iD8DBQFAx26jY5Twig3Ge + YRAkiEAJ94CjEWm7jaNLhUWqMTPZ xh5 + f8YQCgmkau
Y8Q68BHCViU0tzj3vVjrW7U =
= 9d0w
----- END PGP SIGNATURE -----
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.0.6 (GNU/Linux)
Comment: For info see http://www.gnupg.org
iD8DBQFAx26jY5Twig3Ge+YRAkiEAJ94CjEWm7jaNLhUWqMTPZ xh5+f8YQCgmkau
Y8Q68BHCViU0tzj3vVjrW7U=
=9d0w
-----END PGP SIGNATURE-----
2004年6月9日星期三上午9：00：31 + 0200，Henrik Steffen写道：
On Wed, Jun 09, 2004 at 09:00:31AM +0200, Henrik Steffen wrote:
大家好，我在master-db-server上运行postgres 7.4.1，
我有两台运行postgres的奴隶服务器7.4.2
< snip>
在7.4.1到7.4.2之间是否存在这样的差异？
延迟722 ms是不可接受的我，我不喜欢不明白为什么不使用索引。
你有什么想法吗？我已多次运行VACUUM ANALYZE，并且REINDEX TABLE foo甚至
DROPped和reCREATEd索引。没有帮助。
经典问题是数据库的编码。除了C之外还有其他什么比b和b更不喜欢使用索引。
另外，你对两者进行了真空分析，对吧？
希望这会有所帮助，
-
Martijn van Oosterhout< kl ***** @ svana.org> http://svana.org/kleptog/ 专利。 ñ。天才是5％的灵感和95％的汗水。专利是一种工具，用于完成5％的工作，然后坐在那里等待某人其他95％，这样你就可以起诉他们。
hello all,
on my master-db-server i''m running postgres 7.4.1,
and I have got two slave-servers running postgres 7.4.2
<snip>
Is there such a difference in 7.4.1 to 7.4.2 ?
A retardation of 722 ms is not acceptable for me, and I don''t see why
the indexes are not used.
Do you have an idea? I have run VACUUM ANALYZE several times, and
REINDEX TABLE foo and even
DROPped and reCREATEd the index. Didn''t help.
The classic issue is what encoding are the databases. Anything other
than C and like won''t use indexes.
Also, you did a vacuum analyze on both, right?
Hope this helps,
--
Martijn van Oosterhout <kl*****@svana.org> http://svana.org/kleptog/ Patent. n. Genius is 5% inspiration and 95% perspiration. A patent is a
tool for doing 5% of the work and then sitting around waiting for someone
else to do the other 95% so you can sue them.
----- BEGIN PGP SIGNATURE -----
版本：GnuPG v1.0.6（GNU / Linux）
评论：有关信息请参阅 http://www.gnupg.org
iD8DBQFAx26jY5Twig3Ge + YRAkiEAJ94CjEWm7jaNLhUWqMTPZ xh5 + f8YQCgmkau
Y8Q68BHCViU0tzj3vVjrW7U =
= 9d0w
----- END PGP SIGNATURE -----
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.0.6 (GNU/Linux)
Comment: For info see http://www.gnupg.org
iD8DBQFAx26jY5Twig3Ge+YRAkiEAJ94CjEWm7jaNLhUWqMTPZ xh5+f8YQCgmkau
Y8Q68BHCViU0tzj3vVjrW7U=
=9d0w
-----END PGP SIGNATURE-----
Martijn van Oosterhout写道：
Martijn van Oosterhout wrote:
经典问题是编码是什么数据库。除了C之外的任何其他东西都不会使用索引。
The classic issue is what encoding are the databases. Anything other
than C and like won''t use indexes.
除非你使用text_pattern_ops。参见
http：//www.postgresql .org / docs / 7.4 / s ... s-opclass.html
我认为这需要在常见问题解答中。
---------------------------（播出结束）-------------- -------------
提示9：如果您的
加入专栏，计划员将无视您选择索引扫描的愿望数据类型不匹配
Unless you use text_pattern_ops. See
http://www.postgresql.org/docs/7.4/s...s-opclass.html
I think this needs to be in the faq.
---------------------------(end of broadcast)---------------------------
TIP 9: the planner will ignore your desire to choose an index scan if your
joining column''s datatypes do not match
这篇关于使用LIKE索引的文章就介绍到这了，希望我们推荐的答案对大家有所帮助，也希望大家多多支持IT屋！
