From iwasakims @ nttdata.co.jp Wed Dec 12 14:12:49 2007 From: iwasakims @ nttdata.co.jp (iwasakims @ nttdata.co.jp) Date: Wed, 12 Dec 2007 14:12:49 +0900 Subject: [Ludia-users 141] =?iso-2022-jp?b?THVkaWEgMS40LjAgGyRCJHIlaiVqITwlOSQ3JF4kNyQ/GyhC?= Message-ID: 岩崎です。こんにちは。 Ludia 1.4.0 をリリースしました。 以下のような変更内容を含んでいます。 - text型配列に対するインデックス作成機能を追加 - コスト推定関数の改善 - シーケンシャルスキャン時の動作の改善 - 高速カウント関数への対応 - 全文検索クエリのキャッシュによる高速化 不具合等に気づかれましたら、 ぜひご報告いただければと思います。 よろしくおねがいします。 -- 岩崎 正剛 / IWASAKI Masatake mailto:iwasakims @ nttdata.co.jp From ssenou @ techno-mark.co.jp Thu Dec 13 11:26:56 2007 From: ssenou @ techno-mark.co.jp (ssenou) Date: Thu, 13 Dec 2007 11:26:56 +0900 Subject: [Ludia-users 142] =?iso-2022-jp?b?GyRCSiM/dCROJUYhPCVWJWskS0JQJDkka0E0Sjg4ITp3GyhC?= =?iso-2022-jp?b?GyRCJEskRCQkJEYbKEI=?= Message-ID: <003601c83d2f$a2352bd0$c6c8020a@vapor> 瀬能です。 お世話になっています。 質問があるのですが、 複数のテーブル(text型カラム)に対する複数の@@検索を実行すると 必ずシーケンシャルスキャンになってしまうのですが、 複数のテーブル(text型カラム)に対する複数の@@検索は想定していない仕様ですか? (SQL文で対応出来ない事もないですが、できるだけ自由な記述をしたいと思っているので…) また、回避方法などあれば教えてください。 以上よろしくお願いします。 ■環境 Redhat Enterprise Linux 4 U5 ludia 1.4.0 (mecab-0.96 ipadic-2.7.0 senna-1.0.9 postgresql 8.2.4 ■設定 postgres.conf ・ludia.max_n_sort_result = 100000 ・ludia.enable_seqscan = off ・ludia_sen_index_flags = 31 ・ludia.max_n_index_cache = 16 ・ludia.initial_n_segments = 2048 ・ludia.usegenericcost = on or off共に ■DB ・table1(構成) : id(key) int4,data text ・table2(構成) : id(key) int4,data text ・table1(DATA) : id = 1,data = "TEST" ・table2(DATA) : id = 1,data = "TEST" ・table1(INDEX) : fulltextb ・table2(INDEX) : fulltextb ■現象 SELECT * FROM test1,test2 WHERE table1.data @@ 'TEST' or table2.data @@ 'TEST' と実行すると "Nested Loop (cost=0.00..2.04 rows=1 width=24)" " Join Filter: ((table1.data @@ 'TEST'::text) OR (table2.data @@ 'TEST'::text))" " -> Seq Scan on table1 (cost=0.00..1.01 rows=1 width=12)" " -> Seq Scan on table2 (cost=0.00..1.01 rows=1 width=12)" とシーケンシャルスキャンになってしまいます。 From kousakadi @ nttdata.co.jp Thu Dec 13 11:40:25 2007 From: kousakadi @ nttdata.co.jp (kousakadi @ nttdata.co.jp) Date: Thu, 13 Dec 2007 11:40:25 +0900 Subject: [Ludia-users 143] Re: =?iso-2022-jp?b?GyRCSiM/dCROJUYhPCVWJWskS0JQJDkka0E0SjgbKEI=?= =?iso-2022-jp?b?GyRCOCE6dyRLJEQkJCRGGyhC?= References: <003601c83d2f$a2352bd0$c6c8020a@vapor> Message-ID: <178CD7FD87EF4B4BB23F3D0B6C201D3F048F7869@MAILSV11.msg.nttdata.co.jp> 幸坂です。こんにちは。 レコードが1行しかないため、シーケンシャルスキャンのほうが 高速と判断されています。 ・レコード数を増やす。 ・postgresql.conf にenable_seqscan = off と記述する。 などの方法を用いれば、インデックススキャンが利用されるはずです。 > -----Original Message----- > From: ludia-users-bounces @ lists.sourceforge.jp > [mailto:ludia-users-bounces @ lists.sourceforge.jp] On Behalf Of ssenou > Sent: Thursday, December 13, 2007 11:27 AM > To: ludia-users @ lists.sourceforge.jp > Subject: [Ludia-users 142]複数のテーブルに対する全文検索について > > 瀬能です。 > お世話になっています。 > > 質問があるのですが、 > 複数のテーブル(text型カラム)に対する複数の@@検索を実行すると > 必ずシーケンシャルスキャンになってしまうのですが、 > 複数のテーブル(text型カラム)に対する複数の@@検索は想定していない仕様です か? > (SQL文で対応出来ない事もないですが、できるだけ自由な記述をしたいと思ってい るので…) > また、回避方法などあれば教えてください。 > > 以上よろしくお願いします。 > > ■環境 > Redhat Enterprise Linux 4 U5 > ludia 1.4.0 (mecab-0.96 ipadic-2.7.0 senna-1.0.9 > postgresql 8.2.4 > > ■設定 > postgres.conf > ・ludia.max_n_sort_result = 100000 > ・ludia.enable_seqscan = off > ・ludia_sen_index_flags = 31 > ・ludia.max_n_index_cache = 16 > ・ludia.initial_n_segments = 2048 > ・ludia.usegenericcost = on or off共に > > ■DB > ・table1(構成) : id(key) int4,data text > ・table2(構成) : id(key) int4,data text > ・table1(DATA) : id = 1,data = "TEST" > ・table2(DATA) : id = 1,data = "TEST" > ・table1(INDEX) : fulltextb > ・table2(INDEX) : fulltextb > > ■現象 > SELECT * FROM test1,test2 > WHERE table1.data @@ 'TEST' or table2.data @@ 'TEST' > > と実行すると > > "Nested Loop (cost=0.00..2.04 rows=1 width=24)" > " Join Filter: ((table1.data @@ 'TEST'::text) OR (table2.data @@ > 'TEST'::text))" > " -> Seq Scan on table1 (cost=0.00..1.01 rows=1 width=12)" > " -> Seq Scan on table2 (cost=0.00..1.01 rows=1 width=12)" > > とシーケンシャルスキャンになってしまいます。 > > _______________________________________________ > Ludia-users mailing list > Ludia-users @ lists.sourceforge.jp > http://lists.sourceforge.jp/mailman/listinfo/ludia-users > From ssenou @ techno-mark.co.jp Thu Dec 13 11:53:04 2007 From: ssenou @ techno-mark.co.jp (ssenou) Date: Thu, 13 Dec 2007 11:53:04 +0900 Subject: [Ludia-users 144] Re: =?iso-2022-jp?b?GyRCSiM/dCROJUYhPCVWJWskS0JQJDkka0E0SjgbKEI=?= =?iso-2022-jp?b?GyRCOCE6dyRLJEQkJCRGGyhC?= References: <003601c83d2f$a2352bd0$c6c8020a@vapor> <178CD7FD87EF4B4BB23F3D0B6C201D3F048F7869@MAILSV11.msg.nttdata.co.jp> Message-ID: <003f01c83d33$48852190$c6c8020a@vapor> 回答ありがとうございます。 > レコードが1行しかないため、シーケンシャルスキャンのほうが > 高速と判断されています。 データを10万行でも試してみたのですが、 1行も10万行も実行計画に変化が無いので サンプルを1行として質問していました。 > ・postgresql.conf にenable_seqscan = off と記述する。 この設定をして明示的にERRORが発生するようにしています。 ludia1.3系や従来のコスト計算モードでも試したのですが、 結果は同じでした。 以上よろしくお願いします。 ----- Original Message ----- From: To: Sent: Thursday, December 13, 2007 11:40 AM Subject: [Ludia-users 143] Re: 複数のテーブルに対する全文検索について > 幸坂です。こんにちは。 > > レコードが1行しかないため、シーケンシャルスキャンのほうが > 高速と判断されています。 > > ・レコード数を増やす。 > ・postgresql.conf にenable_seqscan = off と記述する。 > > などの方法を用いれば、インデックススキャンが利用されるはずです。 > >> -----Original Message----- >> From: ludia-users-bounces @ lists.sourceforge.jp >> [mailto:ludia-users-bounces @ lists.sourceforge.jp] On Behalf Of ssenou >> Sent: Thursday, December 13, 2007 11:27 AM >> To: ludia-users @ lists.sourceforge.jp >> Subject: [Ludia-users 142]複数のテーブルに対する全文検索について >> >> 瀬能です。 >> お世話になっています。 >> >> 質問があるのですが、 >> 複数のテーブル(text型カラム)に対する複数の@@検索を実行すると >> 必ずシーケンシャルスキャンになってしまうのですが、 >> 複数のテーブル(text型カラム)に対する複数の@@検索は想定していない仕様です > か? >> (SQL文で対応出来ない事もないですが、できるだけ自由な記述をしたいと思ってい >> > るので…) >> また、回避方法などあれば教えてください。 >> >> 以上よろしくお願いします。 >> >> ■環境 >> Redhat Enterprise Linux 4 U5 >> ludia 1.4.0 (mecab-0.96 ipadic-2.7.0 senna-1.0.9 >> postgresql 8.2.4 >> >> ■設定 >> postgres.conf >> ・ludia.max_n_sort_result = 100000 >> ・ludia.enable_seqscan = off >> ・ludia_sen_index_flags = 31 >> ・ludia.max_n_index_cache = 16 >> ・ludia.initial_n_segments = 2048 >> ・ludia.usegenericcost = on or off共に >> >> ■DB >> ・table1(構成) : id(key) int4,data text >> ・table2(構成) : id(key) int4,data text >> ・table1(DATA) : id = 1,data = "TEST" >> ・table2(DATA) : id = 1,data = "TEST" >> ・table1(INDEX) : fulltextb >> ・table2(INDEX) : fulltextb >> >> ■現象 >> SELECT * FROM test1,test2 >> WHERE table1.data @@ 'TEST' or table2.data @@ 'TEST' >> >> と実行すると >> >> "Nested Loop (cost=0.00..2.04 rows=1 width=24)" >> " Join Filter: ((table1.data @@ 'TEST'::text) OR (table2.data @@ >> 'TEST'::text))" >> " -> Seq Scan on table1 (cost=0.00..1.01 rows=1 width=12)" >> " -> Seq Scan on table2 (cost=0.00..1.01 rows=1 width=12)" >> >> とシーケンシャルスキャンになってしまいます。 >> >> _______________________________________________ >> Ludia-users mailing list >> Ludia-users @ lists.sourceforge.jp >> http://lists.sourceforge.jp/mailman/listinfo/ludia-users >> > > _______________________________________________ > Ludia-users mailing list > Ludia-users @ lists.sourceforge.jp > http://lists.sourceforge.jp/mailman/listinfo/ludia-users > > From kousakadi @ nttdata.co.jp Thu Dec 13 14:33:54 2007 From: kousakadi @ nttdata.co.jp (kousakadi @ nttdata.co.jp) Date: Thu, 13 Dec 2007 14:33:54 +0900 Subject: [Ludia-users 145] Re: =?iso-2022-jp?b?GyRCSiM/dCROJUYhPCVWJWskS0JQJDkka0E0SjgbKEI=?= =?iso-2022-jp?b?GyRCOCE6dyRLJEQkJCRGGyhC?= References: <003601c83d2f$a2352bd0$c6c8020a@vapor><178CD7FD87EF4B4BB23F3D0B6C201D3F048F7869@MAILSV11.msg.nttdata.co.jp> <003f01c83d33$48852190$c6c8020a@vapor> Message-ID: <178CD7FD87EF4B4BB23F3D0B6C201D3F048F786D@MAILSV11.msg.nttdata.co.jp> 幸坂です。 >> ・postgresql.conf にenable_seqscan = off と記述する。 > この設定をして明示的にERRORが発生するようにしています。 enable_seqscanとludia.enable_seqscanは別です。 enable_seqscanをoffにすると、シーケンシャルスキャンのコストが高くなり、 インデックススキャンが使われやすくなります。 Ludia以外のコストも変わってしまうので注意して下さい。 瀬能さんが設定したludia.enable_seqscan = offは、 シーケンシャルスキャンの時にERRORが発生しますが、 コスト計算とは全く関係ありません。 enable_seqscanを試してみてください。 >>> SELECT * FROM test1,test2 >>> WHERE table1.data @@ 'TEST' or table2.data @@ 'TEST' このクエリは、table1で1件以上ヒットすると、 table2のレコードが全て結果レコードに含まれます。 つまり、table2は全レコードがアクセスされる可能性が高いです。 同様に、table1も全レコードがアクセスされる可能性が高いです。 全レコードがアクセスされている場合にインデックススキャンを行うと、 全レコードに加えてインデックスにもアクセスする必要があり、 ディスクアクセスが多くなってしまいます。 そのため、今回のプランではシーケンシャルスキャンが選択されています。 クエリは間違っていないですよね? > -----Original Message----- > From: ludia-users-bounces @ lists.sourceforge.jp > [mailto:ludia-users-bounces @ lists.sourceforge.jp] On Behalf Of ssenou > Sent: Thursday, December 13, 2007 11:53 AM > To: ludia-users @ lists.sourceforge.jp > Subject: [Ludia-users 144] Re:複数のテーブルに対する全文検索について > > 回答ありがとうございます。 > > > レコードが1行しかないため、シーケンシャルスキャンのほうが > > 高速と判断されています。 > > データを10万行でも試してみたのですが、 > 1行も10万行も実行計画に変化が無いので > サンプルを1行として質問していました。 > > > ・postgresql.conf にenable_seqscan = off と記述する。 > > この設定をして明示的にERRORが発生するようにしています。 > > ludia1.3系や従来のコスト計算モードでも試したのですが、 > 結果は同じでした。 > > 以上よろしくお願いします。 > > > ----- Original Message ----- > From: > To: > Sent: Thursday, December 13, 2007 11:40 AM > Subject: [Ludia-users 143] Re: 複数のテーブルに対する全文検索について > > > > 幸坂です。こんにちは。 > > > > レコードが1行しかないため、シーケンシャルスキャンのほうが > > 高速と判断されています。 > > > > ・レコード数を増やす。 > > ・postgresql.conf にenable_seqscan = off と記述する。 > > > > などの方法を用いれば、インデックススキャンが利用されるはずです。 > > > >> -----Original Message----- > >> From: ludia-users-bounces @ lists.sourceforge.jp > >> [mailto:ludia-users-bounces @ lists.sourceforge.jp] On > Behalf Of ssenou > >> Sent: Thursday, December 13, 2007 11:27 AM > >> To: ludia-users @ lists.sourceforge.jp > >> Subject: [Ludia-users 142]複数のテーブルに対する全文検索について > >> > >> 瀬能です。 > >> お世話になっています。 > >> > >> 質問があるのですが、 > >> 複数のテーブル(text型カラム)に対する複数の@@検索を実行すると > >> 必ずシーケンシャルスキャンになってしまうのですが、 > >> 複数のテーブル(text型カラム)に対する複数の@@検索は想定していない仕様で す > > か? > >> (SQL文で対応出来ない事もないですが、できるだけ自由な記述をしたいと思っ てい > >> > > るので…) > >> また、回避方法などあれば教えてください。 > >> > >> 以上よろしくお願いします。 > >> > >> ■環境 > >> Redhat Enterprise Linux 4 U5 > >> ludia 1.4.0 (mecab-0.96 ipadic-2.7.0 senna-1.0.9 > >> postgresql 8.2.4 > >> > >> ■設定 > >> postgres.conf > >> ・ludia.max_n_sort_result = 100000 > >> ・ludia.enable_seqscan = off > >> ・ludia_sen_index_flags = 31 > >> ・ludia.max_n_index_cache = 16 > >> ・ludia.initial_n_segments = 2048 > >> ・ludia.usegenericcost = on or off共に > >> > >> ■DB > >> ・table1(構成) : id(key) int4,data text > >> ・table2(構成) : id(key) int4,data text > >> ・table1(DATA) : id = 1,data = "TEST" > >> ・table2(DATA) : id = 1,data = "TEST" > >> ・table1(INDEX) : fulltextb > >> ・table2(INDEX) : fulltextb > >> > >> ■現象 > >> SELECT * FROM test1,test2 > >> WHERE table1.data @@ 'TEST' or table2.data @@ 'TEST' > >> > >> と実行すると > >> > >> "Nested Loop (cost=0.00..2.04 rows=1 width=24)" > >> " Join Filter: ((table1.data @@ 'TEST'::text) OR (table2.data @@ > >> 'TEST'::text))" > >> " -> Seq Scan on table1 (cost=0.00..1.01 rows=1 width=12)" > >> " -> Seq Scan on table2 (cost=0.00..1.01 rows=1 width=12)" > >> > >> とシーケンシャルスキャンになってしまいます。 > >> > >> _______________________________________________ > >> Ludia-users mailing list > >> Ludia-users @ lists.sourceforge.jp > >> http://lists.sourceforge.jp/mailman/listinfo/ludia-users > >> > > > > _______________________________________________ > > Ludia-users mailing list > > Ludia-users @ lists.sourceforge.jp > > http://lists.sourceforge.jp/mailman/listinfo/ludia-users > > > > > > _______________________________________________ > Ludia-users mailing list > Ludia-users @ lists.sourceforge.jp > http://lists.sourceforge.jp/mailman/listinfo/ludia-users > From ssenou @ techno-mark.co.jp Thu Dec 13 15:14:47 2007 From: ssenou @ techno-mark.co.jp (ssenou) Date: Thu, 13 Dec 2007 15:14:47 +0900 Subject: [Ludia-users 146] Re: =?iso-2022-jp?b?GyRCSiM/dCROJUYhPCVWJWskS0JQJDkka0E0SjgbKEI=?= =?iso-2022-jp?b?GyRCOCE6dyRLJEQkJCRGGyhC?= References: <003601c83d2f$a2352bd0$c6c8020a@vapor><178CD7FD87EF4B4BB23F3D0B6C201D3F048F7869@MAILSV11.msg.nttdata.co.jp><003f01c83d33$48852190$c6c8020a@vapor> <178CD7FD87EF4B4BB23F3D0B6C201D3F048F786D@MAILSV11.msg.nttdata.co.jp> Message-ID: <005801c83d4f$769cfe10$c6c8020a@vapor> すいません。 クエリを間違えていました。 下記でお願いします。 SELECT * FROM table1,table2 WHERE table1.id = table2.id AND table1.data @@ 'TEST' or table2.data @@ 'TEST' ----- Original Message ----- From: To: Sent: Thursday, December 13, 2007 2:33 PM Subject: [Ludia-users 145] Re: 複数のテーブルに対する全文検索について > 幸坂です。 > >>> ・postgresql.conf にenable_seqscan = off と記述する。 >> この設定をして明示的にERRORが発生するようにしています。 > enable_seqscanとludia.enable_seqscanは別です。 > enable_seqscanをoffにすると、シーケンシャルスキャンのコストが高くなり、 > インデックススキャンが使われやすくなります。 > Ludia以外のコストも変わってしまうので注意して下さい。 > 瀬能さんが設定したludia.enable_seqscan = offは、 > シーケンシャルスキャンの時にERRORが発生しますが、 > コスト計算とは全く関係ありません。 > enable_seqscanを試してみてください。 > > >>>> SELECT * FROM test1,test2 >>>> WHERE table1.data @@ 'TEST' or table2.data @@ 'TEST' > このクエリは、table1で1件以上ヒットすると、 > table2のレコードが全て結果レコードに含まれます。 > つまり、table2は全レコードがアクセスされる可能性が高いです。 > 同様に、table1も全レコードがアクセスされる可能性が高いです。 > > 全レコードがアクセスされている場合にインデックススキャンを行うと、 > 全レコードに加えてインデックスにもアクセスする必要があり、 > ディスクアクセスが多くなってしまいます。 > そのため、今回のプランではシーケンシャルスキャンが選択されています。 > > クエリは間違っていないですよね? > >> -----Original Message----- >> From: ludia-users-bounces @ lists.sourceforge.jp >> [mailto:ludia-users-bounces @ lists.sourceforge.jp] On Behalf Of ssenou >> Sent: Thursday, December 13, 2007 11:53 AM >> To: ludia-users @ lists.sourceforge.jp >> Subject: [Ludia-users 144] Re:複数のテーブルに対する全文検索について >> >> 回答ありがとうございます。 >> >> > レコードが1行しかないため、シーケンシャルスキャンのほうが >> > 高速と判断されています。 >> >> データを10万行でも試してみたのですが、 >> 1行も10万行も実行計画に変化が無いので >> サンプルを1行として質問していました。 >> >> > ・postgresql.conf にenable_seqscan = off と記述する。 >> >> この設定をして明示的にERRORが発生するようにしています。 >> >> ludia1.3系や従来のコスト計算モードでも試したのですが、 >> 結果は同じでした。 >> >> 以上よろしくお願いします。 >> >> >> ----- Original Message ----- >> From: >> To: >> Sent: Thursday, December 13, 2007 11:40 AM >> Subject: [Ludia-users 143] Re: 複数のテーブルに対する全文検索について >> >> >> > 幸坂です。こんにちは。 >> > >> > レコードが1行しかないため、シーケンシャルスキャンのほうが >> > 高速と判断されています。 >> > >> > ・レコード数を増やす。 >> > ・postgresql.conf にenable_seqscan = off と記述する。 >> > >> > などの方法を用いれば、インデックススキャンが利用されるはずです。 >> > >> >> -----Original Message----- >> >> From: ludia-users-bounces @ lists.sourceforge.jp >> >> [mailto:ludia-users-bounces @ lists.sourceforge.jp] On >> Behalf Of ssenou >> >> Sent: Thursday, December 13, 2007 11:27 AM >> >> To: ludia-users @ lists.sourceforge.jp >> >> Subject: [Ludia-users 142]複数のテーブルに対する全文検索について >> >> >> >> 瀬能です。 >> >> お世話になっています。 >> >> >> >> 質問があるのですが、 >> >> 複数のテーブル(text型カラム)に対する複数の@@検索を実行すると >> >> 必ずシーケンシャルスキャンになってしまうのですが、 >> >> 複数のテーブル(text型カラム)に対する複数の@@検索は想定していない仕様で > す >> > か? >> >> (SQL文で対応出来ない事もないですが、できるだけ自由な記述をしたいと思っ > てい >> >> >> > るので…) >> >> また、回避方法などあれば教えてください。 >> >> >> >> 以上よろしくお願いします。 >> >> >> >> ■環境 >> >> Redhat Enterprise Linux 4 U5 >> >> ludia 1.4.0 (mecab-0.96 ipadic-2.7.0 senna-1.0.9 >> >> postgresql 8.2.4 >> >> >> >> ■設定 >> >> postgres.conf >> >> ・ludia.max_n_sort_result = 100000 >> >> ・ludia.enable_seqscan = off >> >> ・ludia_sen_index_flags = 31 >> >> ・ludia.max_n_index_cache = 16 >> >> ・ludia.initial_n_segments = 2048 >> >> ・ludia.usegenericcost = on or off共に >> >> >> >> ■DB >> >> ・table1(構成) : id(key) int4,data text >> >> ・table2(構成) : id(key) int4,data text >> >> ・table1(DATA) : id = 1,data = "TEST" >> >> ・table2(DATA) : id = 1,data = "TEST" >> >> ・table1(INDEX) : fulltextb >> >> ・table2(INDEX) : fulltextb >> >> >> >> ■現象 >> >> SELECT * FROM test1,test2 >> >> WHERE table1.data @@ 'TEST' or table2.data @@ 'TEST' >> >> >> >> と実行すると >> >> >> >> "Nested Loop (cost=0.00..2.04 rows=1 width=24)" >> >> " Join Filter: ((table1.data @@ 'TEST'::text) OR (table2.data @@ >> >> 'TEST'::text))" >> >> " -> Seq Scan on table1 (cost=0.00..1.01 rows=1 width=12)" >> >> " -> Seq Scan on table2 (cost=0.00..1.01 rows=1 width=12)" >> >> >> >> とシーケンシャルスキャンになってしまいます。 >> >> >> >> _______________________________________________ >> >> Ludia-users mailing list >> >> Ludia-users @ lists.sourceforge.jp >> >> http://lists.sourceforge.jp/mailman/listinfo/ludia-users >> >> >> > >> > _______________________________________________ >> > Ludia-users mailing list >> > Ludia-users @ lists.sourceforge.jp >> > http://lists.sourceforge.jp/mailman/listinfo/ludia-users >> > >> > >> >> _______________________________________________ >> Ludia-users mailing list >> Ludia-users @ lists.sourceforge.jp >> http://lists.sourceforge.jp/mailman/listinfo/ludia-users >> > > _______________________________________________ > Ludia-users mailing list > Ludia-users @ lists.sourceforge.jp > http://lists.sourceforge.jp/mailman/listinfo/ludia-users > > From kousakadi @ nttdata.co.jp Thu Dec 13 16:04:01 2007 From: kousakadi @ nttdata.co.jp (kousakadi @ nttdata.co.jp) Date: Thu, 13 Dec 2007 16:04:01 +0900 Subject: [Ludia-users 147] Re: =?iso-2022-jp?b?GyRCSiM/dCROJUYhPCVWJWskS0JQJDkka0E0SjgbKEI=?= =?iso-2022-jp?b?GyRCOCE6dyRLJEQkJCRGGyhC?= References: <003601c83d2f$a2352bd0$c6c8020a@vapor><178CD7FD87EF4B4BB23F3D0B6C201D3F048F7869@MAILSV11.msg.nttdata.co.jp><003f01c83d33$48852190$c6c8020a@vapor><178CD7FD87EF4B4BB23F3D0B6C201D3F048F786D@MAILSV11.msg.nttdata.co.jp> <005801c83d4f$769cfe10$c6c8020a@vapor> Message-ID: <178CD7FD87EF4B4BB23F3D0B6C201D3F048F786F@MAILSV11.msg.nttdata.co.jp> 幸坂です。 SELECT * FROM table1,table2 WHERE table1.id = table2.id AND (table1.data @@ 'TEST' or table2.data @@ 'TEST'); と間違えていませんか? > SELECT * FROM table1,table2 > WHERE > table1.id = table2.id AND > table1.data @@ 'TEST' or table2.data @@ 'TEST' ORよりANDのほうが優先順位が高いため、このクエリは、 SELECT * FROM table1,table2 WHERE (table1.id = table2.id AND table1.data @@ 'TEST') or table2.data @@ 'TEST'; と同じです。 http://www.postgresql.jp/document/pg825doc/html/sql-syntax-lexical.html 表 4-1. 演算子の優先順位(強いものから) > -----Original Message----- > From: ludia-users-bounces @ lists.sourceforge.jp > [mailto:ludia-users-bounces @ lists.sourceforge.jp] On Behalf Of ssenou > Sent: Thursday, December 13, 2007 3:15 PM > To: ludia-users @ lists.sourceforge.jp > Subject: [Ludia-users 146] Re:複数のテーブルに対する全文検索について > > すいません。 > > クエリを間違えていました。 > > 下記でお願いします。 > > SELECT * FROM table1,table2 > WHERE > table1.id = table2.id AND > table1.data @@ 'TEST' or table2.data @@ 'TEST' > > > ----- Original Message ----- > From: > To: > Sent: Thursday, December 13, 2007 2:33 PM > Subject: [Ludia-users 145] Re: 複数のテーブルに対する全文検索について > > > > 幸坂です。 > > > >>> ・postgresql.conf にenable_seqscan = off と記述する。 > >> この設定をして明示的にERRORが発生するようにしています。 > > enable_seqscanとludia.enable_seqscanは別です。 > > enable_seqscanをoffにすると、シーケンシャルスキャンのコストが高くなり、 > > インデックススキャンが使われやすくなります。 > > Ludia以外のコストも変わってしまうので注意して下さい。 > > 瀬能さんが設定したludia.enable_seqscan = offは、 > > シーケンシャルスキャンの時にERRORが発生しますが、 > > コスト計算とは全く関係ありません。 > > enable_seqscanを試してみてください。 > > > > > >>>> SELECT * FROM test1,test2 > >>>> WHERE table1.data @@ 'TEST' or table2.data @@ 'TEST' > > このクエリは、table1で1件以上ヒットすると、 > > table2のレコードが全て結果レコードに含まれます。 > > つまり、table2は全レコードがアクセスされる可能性が高いです。 > > 同様に、table1も全レコードがアクセスされる可能性が高いです。 > > > > 全レコードがアクセスされている場合にインデックススキャンを行うと、 > > 全レコードに加えてインデックスにもアクセスする必要があり、 > > ディスクアクセスが多くなってしまいます。 > > そのため、今回のプランではシーケンシャルスキャンが選択されています。 > > > > クエリは間違っていないですよね? > > > >> -----Original Message----- > >> From: ludia-users-bounces @ lists.sourceforge.jp > >> [mailto:ludia-users-bounces @ lists.sourceforge.jp] On > Behalf Of ssenou > >> Sent: Thursday, December 13, 2007 11:53 AM > >> To: ludia-users @ lists.sourceforge.jp > >> Subject: [Ludia-users 144] Re:複数のテーブルに対する全文検索について > >> > >> 回答ありがとうございます。 > >> > >> > レコードが1行しかないため、シーケンシャルスキャンのほうが > >> > 高速と判断されています。 > >> > >> データを10万行でも試してみたのですが、 > >> 1行も10万行も実行計画に変化が無いので > >> サンプルを1行として質問していました。 > >> > >> > ・postgresql.conf にenable_seqscan = off と記述する。 > >> > >> この設定をして明示的にERRORが発生するようにしています。 > >> > >> ludia1.3系や従来のコスト計算モードでも試したのですが、 > >> 結果は同じでした。 > >> > >> 以上よろしくお願いします。 > >> > >> > >> ----- Original Message ----- > >> From: > >> To: > >> Sent: Thursday, December 13, 2007 11:40 AM > >> Subject: [Ludia-users 143] Re: 複数のテーブルに対する全文検索について > >> > >> > >> > 幸坂です。こんにちは。 > >> > > >> > レコードが1行しかないため、シーケンシャルスキャンのほうが > >> > 高速と判断されています。 > >> > > >> > ・レコード数を増やす。 > >> > ・postgresql.conf にenable_seqscan = off と記述する。 > >> > > >> > などの方法を用いれば、インデックススキャンが利用されるはずです。 > >> > > >> >> -----Original Message----- > >> >> From: ludia-users-bounces @ lists.sourceforge.jp > >> >> [mailto:ludia-users-bounces @ lists.sourceforge.jp] On > >> Behalf Of ssenou > >> >> Sent: Thursday, December 13, 2007 11:27 AM > >> >> To: ludia-users @ lists.sourceforge.jp > >> >> Subject: [Ludia-users 142]複数のテーブルに対する全文検索について > >> >> > >> >> 瀬能です。 > >> >> お世話になっています。 > >> >> > >> >> 質問があるのですが、 > >> >> 複数のテーブル(text型カラム)に対する複数の@@検索を実行すると > >> >> 必ずシーケンシャルスキャンになってしまうのですが、 > >> >> 複数のテーブル(text型カラム)に対する複数の@@検索は想定していない仕様 で > > す > >> > か? > >> >> (SQL文で対応出来ない事もないですが、できるだけ自由な記述をしたいと 思っ > > てい > >> >> > >> > るので…) > >> >> また、回避方法などあれば教えてください。 > >> >> > >> >> 以上よろしくお願いします。 > >> >> > >> >> ■環境 > >> >> Redhat Enterprise Linux 4 U5 > >> >> ludia 1.4.0 (mecab-0.96 ipadic-2.7.0 senna-1.0.9 > >> >> postgresql 8.2.4 > >> >> > >> >> ■設定 > >> >> postgres.conf > >> >> ・ludia.max_n_sort_result = 100000 > >> >> ・ludia.enable_seqscan = off > >> >> ・ludia_sen_index_flags = 31 > >> >> ・ludia.max_n_index_cache = 16 > >> >> ・ludia.initial_n_segments = 2048 > >> >> ・ludia.usegenericcost = on or off共に > >> >> > >> >> ■DB > >> >> ・table1(構成) : id(key) int4,data text > >> >> ・table2(構成) : id(key) int4,data text > >> >> ・table1(DATA) : id = 1,data = "TEST" > >> >> ・table2(DATA) : id = 1,data = "TEST" > >> >> ・table1(INDEX) : fulltextb > >> >> ・table2(INDEX) : fulltextb > >> >> > >> >> ■現象 > >> >> SELECT * FROM test1,test2 > >> >> WHERE table1.data @@ 'TEST' or table2.data @@ 'TEST' > >> >> > >> >> と実行すると > >> >> > >> >> "Nested Loop (cost=0.00..2.04 rows=1 width=24)" > >> >> " Join Filter: ((table1.data @@ 'TEST'::text) OR > (table2.data @@ > >> >> 'TEST'::text))" > >> >> " -> Seq Scan on table1 (cost=0.00..1.01 rows=1 width=12)" > >> >> " -> Seq Scan on table2 (cost=0.00..1.01 rows=1 width=12)" > >> >> > >> >> とシーケンシャルスキャンになってしまいます。 > >> >> > >> >> _______________________________________________ > >> >> Ludia-users mailing list > >> >> Ludia-users @ lists.sourceforge.jp > >> >> http://lists.sourceforge.jp/mailman/listinfo/ludia-users > >> >> > >> > > >> > _______________________________________________ > >> > Ludia-users mailing list > >> > Ludia-users @ lists.sourceforge.jp > >> > http://lists.sourceforge.jp/mailman/listinfo/ludia-users > >> > > >> > > >> > >> _______________________________________________ > >> Ludia-users mailing list > >> Ludia-users @ lists.sourceforge.jp > >> http://lists.sourceforge.jp/mailman/listinfo/ludia-users > >> > > > > _______________________________________________ > > Ludia-users mailing list > > Ludia-users @ lists.sourceforge.jp > > http://lists.sourceforge.jp/mailman/listinfo/ludia-users > > > > > > _______________________________________________ > Ludia-users mailing list > Ludia-users @ lists.sourceforge.jp > http://lists.sourceforge.jp/mailman/listinfo/ludia-users > From ssenou @ techno-mark.co.jp Thu Dec 13 17:04:06 2007 From: ssenou @ techno-mark.co.jp (ssenou) Date: Thu, 13 Dec 2007 17:04:06 +0900 Subject: [Ludia-users 148] Re: =?iso-2022-jp?b?GyRCSiM/dCROJUYhPCVWJWskS0JQJDkka0E0SjgbKEI=?= =?iso-2022-jp?b?GyRCOCE6dyRLJEQkJCRGGyhC?= References: <003601c83d2f$a2352bd0$c6c8020a@vapor><178CD7FD87EF4B4BB23F3D0B6C201D3F048F7869@MAILSV11.msg.nttdata.co.jp><003f01c83d33$48852190$c6c8020a@vapor><178CD7FD87EF4B4BB23F3D0B6C201D3F048F786D@MAILSV11.msg.nttdata.co.jp><005801c83d4f$769cfe10$c6c8020a@vapor> <178CD7FD87EF4B4BB23F3D0B6C201D3F048F786F@MAILSV11.msg.nttdata.co.jp> Message-ID: <005f01c83d5e$ddef8060$c6c8020a@vapor> 瀬能です。 すいません、括弧をつけ忘れていました。 正しくは下記です。 SELECT * FROM table1,table2 WHERE table1.id = table2.id AND (table1.data @@ 'TEST' or table2.data @@ 'TEST') 勘違いしていた様で、少し質問を変えさせて下さい。 table1.dataを件名 table2.dataを本文 と見なし 検索対象が"件名又は本文"の場合という検索で 全文検索を実行させたい場合、何かいい方法ありませんか? これくらいしか思い付かなかったのですが… SELECT * FROM table1,table2 WHERE (select id from table1 where data @@ 'AAA') = (select id from table2 where data @@ 'AAA') よろしくお願いします。 ----- Original Message ----- From: To: Sent: Thursday, December 13, 2007 4:04 PM Subject: [Ludia-users 147] Re: 複数のテーブルに対する全文検索について > 幸坂です。 > > SELECT * FROM table1,table2 > WHERE > table1.id = table2.id AND > (table1.data @@ 'TEST' or table2.data @@ 'TEST'); > と間違えていませんか? > >> SELECT * FROM table1,table2 >> WHERE >> table1.id = table2.id AND >> table1.data @@ 'TEST' or table2.data @@ 'TEST' > ORよりANDのほうが優先順位が高いため、このクエリは、 > SELECT * FROM table1,table2 > WHERE > (table1.id = table2.id AND > table1.data @@ 'TEST') or table2.data @@ 'TEST'; > と同じです。 > > http://www.postgresql.jp/document/pg825doc/html/sql-syntax-lexical.html > 表 4-1. 演算子の優先順位(強いものから) > >> -----Original Message----- >> From: ludia-users-bounces @ lists.sourceforge.jp >> [mailto:ludia-users-bounces @ lists.sourceforge.jp] On Behalf Of ssenou >> Sent: Thursday, December 13, 2007 3:15 PM >> To: ludia-users @ lists.sourceforge.jp >> Subject: [Ludia-users 146] Re:複数のテーブルに対する全文検索について >> >> すいません。 >> >> クエリを間違えていました。 >> >> 下記でお願いします。 >> >> SELECT * FROM table1,table2 >> WHERE >> table1.id = table2.id AND >> table1.data @@ 'TEST' or table2.data @@ 'TEST' >> >> >> ----- Original Message ----- >> From: >> To: >> Sent: Thursday, December 13, 2007 2:33 PM >> Subject: [Ludia-users 145] Re: 複数のテーブルに対する全文検索について >> >> >> > 幸坂です。 >> > >> >>> ・postgresql.conf にenable_seqscan = off と記述する。 >> >> この設定をして明示的にERRORが発生するようにしています。 >> > enable_seqscanとludia.enable_seqscanは別です。 >> > enable_seqscanをoffにすると、シーケンシャルスキャンのコストが高くなり、 >> > インデックススキャンが使われやすくなります。 >> > Ludia以外のコストも変わってしまうので注意して下さい。 >> > 瀬能さんが設定したludia.enable_seqscan = offは、 >> > シーケンシャルスキャンの時にERRORが発生しますが、 >> > コスト計算とは全く関係ありません。 >> > enable_seqscanを試してみてください。 >> > >> > >> >>>> SELECT * FROM test1,test2 >> >>>> WHERE table1.data @@ 'TEST' or table2.data @@ 'TEST' >> > このクエリは、table1で1件以上ヒットすると、 >> > table2のレコードが全て結果レコードに含まれます。 >> > つまり、table2は全レコードがアクセスされる可能性が高いです。 >> > 同様に、table1も全レコードがアクセスされる可能性が高いです。 >> > >> > 全レコードがアクセスされている場合にインデックススキャンを行うと、 >> > 全レコードに加えてインデックスにもアクセスする必要があり、 >> > ディスクアクセスが多くなってしまいます。 >> > そのため、今回のプランではシーケンシャルスキャンが選択されています。 >> > >> > クエリは間違っていないですよね? >> > >> >> -----Original Message----- >> >> From: ludia-users-bounces @ lists.sourceforge.jp >> >> [mailto:ludia-users-bounces @ lists.sourceforge.jp] On >> Behalf Of ssenou >> >> Sent: Thursday, December 13, 2007 11:53 AM >> >> To: ludia-users @ lists.sourceforge.jp >> >> Subject: [Ludia-users 144] Re:複数のテーブルに対する全文検索について >> >> >> >> 回答ありがとうございます。 >> >> >> >> > レコードが1行しかないため、シーケンシャルスキャンのほうが >> >> > 高速と判断されています。 >> >> >> >> データを10万行でも試してみたのですが、 >> >> 1行も10万行も実行計画に変化が無いので >> >> サンプルを1行として質問していました。 >> >> >> >> > ・postgresql.conf にenable_seqscan = off と記述する。 >> >> >> >> この設定をして明示的にERRORが発生するようにしています。 >> >> >> >> ludia1.3系や従来のコスト計算モードでも試したのですが、 >> >> 結果は同じでした。 >> >> >> >> 以上よろしくお願いします。 >> >> >> >> >> >> ----- Original Message ----- >> >> From: >> >> To: >> >> Sent: Thursday, December 13, 2007 11:40 AM >> >> Subject: [Ludia-users 143] Re: 複数のテーブルに対する全文検索について >> >> >> >> >> >> > 幸坂です。こんにちは。 >> >> > >> >> > レコードが1行しかないため、シーケンシャルスキャンのほうが >> >> > 高速と判断されています。 >> >> > >> >> > ・レコード数を増やす。 >> >> > ・postgresql.conf にenable_seqscan = off と記述する。 >> >> > >> >> > などの方法を用いれば、インデックススキャンが利用されるはずです。 >> >> > >> >> >> -----Original Message----- >> >> >> From: ludia-users-bounces @ lists.sourceforge.jp >> >> >> [mailto:ludia-users-bounces @ lists.sourceforge.jp] On >> >> Behalf Of ssenou >> >> >> Sent: Thursday, December 13, 2007 11:27 AM >> >> >> To: ludia-users @ lists.sourceforge.jp >> >> >> Subject: [Ludia-users 142]複数のテーブルに対する全文検索について >> >> >> >> >> >> 瀬能です。 >> >> >> お世話になっています。 >> >> >> >> >> >> 質問があるのですが、 >> >> >> 複数のテーブル(text型カラム)に対する複数の@@検索を実行すると >> >> >> 必ずシーケンシャルスキャンになってしまうのですが、 >> >> >> 複数のテーブル(text型カラム)に対する複数の@@検索は想定していない仕様 >> >> >> > で >> > す >> >> > か? >> >> >> (SQL文で対応出来ない事もないですが、できるだけ自由な記述をしたいと > 思っ >> > てい >> >> >> >> >> > るので…) >> >> >> また、回避方法などあれば教えてください。 >> >> >> >> >> >> 以上よろしくお願いします。 >> >> >> >> >> >> ■環境 >> >> >> Redhat Enterprise Linux 4 U5 >> >> >> ludia 1.4.0 (mecab-0.96 ipadic-2.7.0 senna-1.0.9 >> >> >> postgresql 8.2.4 >> >> >> >> >> >> ■設定 >> >> >> postgres.conf >> >> >> ・ludia.max_n_sort_result = 100000 >> >> >> ・ludia.enable_seqscan = off >> >> >> ・ludia_sen_index_flags = 31 >> >> >> ・ludia.max_n_index_cache = 16 >> >> >> ・ludia.initial_n_segments = 2048 >> >> >> ・ludia.usegenericcost = on or off共に >> >> >> >> >> >> ■DB >> >> >> ・table1(構成) : id(key) int4,data text >> >> >> ・table2(構成) : id(key) int4,data text >> >> >> ・table1(DATA) : id = 1,data = "TEST" >> >> >> ・table2(DATA) : id = 1,data = "TEST" >> >> >> ・table1(INDEX) : fulltextb >> >> >> ・table2(INDEX) : fulltextb >> >> >> >> >> >> ■現象 >> >> >> SELECT * FROM test1,test2 >> >> >> WHERE table1.data @@ 'TEST' or table2.data @@ 'TEST' >> >> >> >> >> >> と実行すると >> >> >> >> >> >> "Nested Loop (cost=0.00..2.04 rows=1 width=24)" >> >> >> " Join Filter: ((table1.data @@ 'TEST'::text) OR >> (table2.data @@ >> >> >> 'TEST'::text))" >> >> >> " -> Seq Scan on table1 (cost=0.00..1.01 rows=1 width=12)" >> >> >> " -> Seq Scan on table2 (cost=0.00..1.01 rows=1 width=12)" >> >> >> >> >> >> とシーケンシャルスキャンになってしまいます。 >> >> >> >> >> >> _______________________________________________ >> >> >> Ludia-users mailing list >> >> >> Ludia-users @ lists.sourceforge.jp >> >> >> http://lists.sourceforge.jp/mailman/listinfo/ludia-users >> >> >> >> >> > >> >> > _______________________________________________ >> >> > Ludia-users mailing list >> >> > Ludia-users @ lists.sourceforge.jp >> >> > http://lists.sourceforge.jp/mailman/listinfo/ludia-users >> >> > >> >> > >> >> >> >> _______________________________________________ >> >> Ludia-users mailing list >> >> Ludia-users @ lists.sourceforge.jp >> >> http://lists.sourceforge.jp/mailman/listinfo/ludia-users >> >> >> > >> > _______________________________________________ >> > Ludia-users mailing list >> > Ludia-users @ lists.sourceforge.jp >> > http://lists.sourceforge.jp/mailman/listinfo/ludia-users >> > >> > >> >> _______________________________________________ >> Ludia-users mailing list >> Ludia-users @ lists.sourceforge.jp >> http://lists.sourceforge.jp/mailman/listinfo/ludia-users >> > > _______________________________________________ > Ludia-users mailing list > Ludia-users @ lists.sourceforge.jp > http://lists.sourceforge.jp/mailman/listinfo/ludia-users > > From kousakadi @ nttdata.co.jp Thu Dec 13 17:29:59 2007 From: kousakadi @ nttdata.co.jp (kousakadi @ nttdata.co.jp) Date: Thu, 13 Dec 2007 17:29:59 +0900 Subject: [Ludia-users 149] Re: =?iso-2022-jp?b?GyRCSiM/dCROJUYhPCVWJWskS0JQJDkka0E0SjgbKEI=?= =?iso-2022-jp?b?GyRCOCE6dyRLJEQkJCRGGyhC?= References: <003601c83d2f$a2352bd0$c6c8020a@vapor><178CD7FD87EF4B4BB23F3D0B6C201D3F048F7869@MAILSV11.msg.nttdata.co.jp><003f01c83d33$48852190$c6c8020a@vapor><178CD7FD87EF4B4BB23F3D0B6C201D3F048F786D@MAILSV11.msg.nttdata.co.jp><005801c83d4f$769cfe10$c6c8020a@vapor><178CD7FD87EF4B4BB23F3D0B6C201D3F048F786F@MAILSV11.msg.nttdata.co.jp> <005f01c83d5e$ddef8060$c6c8020a@vapor> Message-ID: <178CD7FD87EF4B4BB23F3D0B6C201D3F048F7871@MAILSV11.msg.nttdata.co.jp> 幸坂です。 このクエリで、いかがでしょうか? select * from (select * from table1 where data @@ 'test') AS t1, (select * from table2 where data @@ 'test') AS t2 WHERE t1.id = t2.id; 速度だけを考えるならば、 table1とtable2を結合したテーブルを定義し、 マルチカラムインデックス(もしくは配列型インデックス)を張ると、 高速になります。 > -----Original Message----- > From: ludia-users-bounces @ lists.sourceforge.jp > [mailto:ludia-users-bounces @ lists.sourceforge.jp] On Behalf Of ssenou > Sent: Thursday, December 13, 2007 5:04 PM > To: ludia-users @ lists.sourceforge.jp > Subject: [Ludia-users 148] Re:複数のテーブルに対する全文検索について > > 瀬能です。 > すいません、括弧をつけ忘れていました。 > 正しくは下記です。 > > SELECT * FROM table1,table2 > WHERE > table1.id = table2.id AND > (table1.data @@ 'TEST' or table2.data @@ 'TEST') > > > 勘違いしていた様で、少し質問を変えさせて下さい。 > > table1.dataを件名 > table2.dataを本文 > と見なし > 検索対象が"件名又は本文"の場合という検索で > 全文検索を実行させたい場合、何かいい方法ありませんか? > > これくらいしか思い付かなかったのですが… > SELECT * FROM table1,table2 > WHERE > (select id from table1 where data @@ 'AAA') = (select id from > table2 where > data @@ 'AAA') > > よろしくお願いします。 > > ----- Original Message ----- > From: > To: > Sent: Thursday, December 13, 2007 4:04 PM > Subject: [Ludia-users 147] Re: 複数のテーブルに対する全文検索について > > > > 幸坂です。 > > > > SELECT * FROM table1,table2 > > WHERE > > table1.id = table2.id AND > > (table1.data @@ 'TEST' or table2.data @@ 'TEST'); > > と間違えていませんか? > > > >> SELECT * FROM table1,table2 > >> WHERE > >> table1.id = table2.id AND > >> table1.data @@ 'TEST' or table2.data @@ 'TEST' > > ORよりANDのほうが優先順位が高いため、このクエリは、 > > SELECT * FROM table1,table2 > > WHERE > > (table1.id = table2.id AND > > table1.data @@ 'TEST') or table2.data @@ 'TEST'; > > と同じです。 > > > > > http://www.postgresql.jp/document/pg825doc/html/sql-syntax-lex > ical.html > > 表 4-1. 演算子の優先順位(強いものから) > > > >> -----Original Message----- > >> From: ludia-users-bounces @ lists.sourceforge.jp > >> [mailto:ludia-users-bounces @ lists.sourceforge.jp] On > Behalf Of ssenou > >> Sent: Thursday, December 13, 2007 3:15 PM > >> To: ludia-users @ lists.sourceforge.jp > >> Subject: [Ludia-users 146] Re:複数のテーブルに対する全文検索について > >> > >> すいません。 > >> > >> クエリを間違えていました。 > >> > >> 下記でお願いします。 > >> > >> SELECT * FROM table1,table2 > >> WHERE > >> table1.id = table2.id AND > >> table1.data @@ 'TEST' or table2.data @@ 'TEST' > >> > >> > >> ----- Original Message ----- > >> From: > >> To: > >> Sent: Thursday, December 13, 2007 2:33 PM > >> Subject: [Ludia-users 145] Re: 複数のテーブルに対する全文検索について > >> > >> > >> > 幸坂です。 > >> > > >> >>> ・postgresql.conf にenable_seqscan = off と記述する。 > >> >> この設定をして明示的にERRORが発生するようにしています。 > >> > enable_seqscanとludia.enable_seqscanは別です。 > >> > enable_seqscanをoffにすると、シーケンシャルスキャンのコストが高くな り、 > >> > インデックススキャンが使われやすくなります。 > >> > Ludia以外のコストも変わってしまうので注意して下さい。 > >> > 瀬能さんが設定したludia.enable_seqscan = offは、 > >> > シーケンシャルスキャンの時にERRORが発生しますが、 > >> > コスト計算とは全く関係ありません。 > >> > enable_seqscanを試してみてください。 > >> > > >> > > >> >>>> SELECT * FROM test1,test2 > >> >>>> WHERE table1.data @@ 'TEST' or table2.data @@ 'TEST' > >> > このクエリは、table1で1件以上ヒットすると、 > >> > table2のレコードが全て結果レコードに含まれます。 > >> > つまり、table2は全レコードがアクセスされる可能性が高いです。 > >> > 同様に、table1も全レコードがアクセスされる可能性が高いです。 > >> > > >> > 全レコードがアクセスされている場合にインデックススキャンを行うと、 > >> > 全レコードに加えてインデックスにもアクセスする必要があり、 > >> > ディスクアクセスが多くなってしまいます。 > >> > そのため、今回のプランではシーケンシャルスキャンが選択されています。 > >> > > >> > クエリは間違っていないですよね? > >> > > >> >> -----Original Message----- > >> >> From: ludia-users-bounces @ lists.sourceforge.jp > >> >> [mailto:ludia-users-bounces @ lists.sourceforge.jp] On > >> Behalf Of ssenou > >> >> Sent: Thursday, December 13, 2007 11:53 AM > >> >> To: ludia-users @ lists.sourceforge.jp > >> >> Subject: [Ludia-users 144] Re:複数のテーブルに対する全文検索について > >> >> > >> >> 回答ありがとうございます。 > >> >> > >> >> > レコードが1行しかないため、シーケンシャルスキャンのほうが > >> >> > 高速と判断されています。 > >> >> > >> >> データを10万行でも試してみたのですが、 > >> >> 1行も10万行も実行計画に変化が無いので > >> >> サンプルを1行として質問していました。 > >> >> > >> >> > ・postgresql.conf にenable_seqscan = off と記述する。 > >> >> > >> >> この設定をして明示的にERRORが発生するようにしています。 > >> >> > >> >> ludia1.3系や従来のコスト計算モードでも試したのですが、 > >> >> 結果は同じでした。 > >> >> > >> >> 以上よろしくお願いします。 > >> >> > >> >> > >> >> ----- Original Message ----- > >> >> From: > >> >> To: > >> >> Sent: Thursday, December 13, 2007 11:40 AM > >> >> Subject: [Ludia-users 143] Re: 複数のテーブルに対する全文検索につい て > >> >> > >> >> > >> >> > 幸坂です。こんにちは。 > >> >> > > >> >> > レコードが1行しかないため、シーケンシャルスキャンのほうが > >> >> > 高速と判断されています。 > >> >> > > >> >> > ・レコード数を増やす。 > >> >> > ・postgresql.conf にenable_seqscan = off と記述する。 > >> >> > > >> >> > などの方法を用いれば、インデックススキャンが利用されるはずです。 > >> >> > > >> >> >> -----Original Message----- > >> >> >> From: ludia-users-bounces @ lists.sourceforge.jp > >> >> >> [mailto:ludia-users-bounces @ lists.sourceforge.jp] On > >> >> Behalf Of ssenou > >> >> >> Sent: Thursday, December 13, 2007 11:27 AM > >> >> >> To: ludia-users @ lists.sourceforge.jp > >> >> >> Subject: [Ludia-users 142]複数のテーブルに対する全文検索について > >> >> >> > >> >> >> 瀬能です。 > >> >> >> お世話になっています。 > >> >> >> > >> >> >> 質問があるのですが、 > >> >> >> 複数のテーブル(text型カラム)に対する複数の@@検索を実行すると > >> >> >> 必ずシーケンシャルスキャンになってしまうのですが、 > >> >> >> 複数のテーブル(text型カラム)に対する複数の@@検索は想定していない 仕様 > >> >> >> > > で > >> > す > >> >> > か? > >> >> >> (SQL文で対応出来ない事もないですが、できるだけ自由な記述をしたい と > > 思っ > >> > てい > >> >> >> > >> >> > るので…) > >> >> >> また、回避方法などあれば教えてください。 > >> >> >> > >> >> >> 以上よろしくお願いします。 > >> >> >> > >> >> >> ■環境 > >> >> >> Redhat Enterprise Linux 4 U5 > >> >> >> ludia 1.4.0 (mecab-0.96 ipadic-2.7.0 senna-1.0.9 > >> >> >> postgresql 8.2.4 > >> >> >> > >> >> >> ■設定 > >> >> >> postgres.conf > >> >> >> ・ludia.max_n_sort_result = 100000 > >> >> >> ・ludia.enable_seqscan = off > >> >> >> ・ludia_sen_index_flags = 31 > >> >> >> ・ludia.max_n_index_cache = 16 > >> >> >> ・ludia.initial_n_segments = 2048 > >> >> >> ・ludia.usegenericcost = on or off共に > >> >> >> > >> >> >> ■DB > >> >> >> ・table1(構成) : id(key) int4,data text > >> >> >> ・table2(構成) : id(key) int4,data text > >> >> >> ・table1(DATA) : id = 1,data = "TEST" > >> >> >> ・table2(DATA) : id = 1,data = "TEST" > >> >> >> ・table1(INDEX) : fulltextb > >> >> >> ・table2(INDEX) : fulltextb > >> >> >> > >> >> >> ■現象 > >> >> >> SELECT * FROM test1,test2 > >> >> >> WHERE table1.data @@ 'TEST' or table2.data @@ 'TEST' > >> >> >> > >> >> >> と実行すると > >> >> >> > >> >> >> "Nested Loop (cost=0.00..2.04 rows=1 width=24)" > >> >> >> " Join Filter: ((table1.data @@ 'TEST'::text) OR > >> (table2.data @@ > >> >> >> 'TEST'::text))" > >> >> >> " -> Seq Scan on table1 (cost=0.00..1.01 rows=1 width=12)" > >> >> >> " -> Seq Scan on table2 (cost=0.00..1.01 rows=1 width=12)" > >> >> >> > >> >> >> とシーケンシャルスキャンになってしまいます。 > >> >> >> > >> >> >> _______________________________________________ > >> >> >> Ludia-users mailing list > >> >> >> Ludia-users @ lists.sourceforge.jp > >> >> >> http://lists.sourceforge.jp/mailman/listinfo/ludia-users > >> >> >> > >> >> > > >> >> > _______________________________________________ > >> >> > Ludia-users mailing list > >> >> > Ludia-users @ lists.sourceforge.jp > >> >> > http://lists.sourceforge.jp/mailman/listinfo/ludia-users > >> >> > > >> >> > > >> >> > >> >> _______________________________________________ > >> >> Ludia-users mailing list > >> >> Ludia-users @ lists.sourceforge.jp > >> >> http://lists.sourceforge.jp/mailman/listinfo/ludia-users > >> >> > >> > > >> > _______________________________________________ > >> > Ludia-users mailing list > >> > Ludia-users @ lists.sourceforge.jp > >> > http://lists.sourceforge.jp/mailman/listinfo/ludia-users > >> > > >> > > >> > >> _______________________________________________ > >> Ludia-users mailing list > >> Ludia-users @ lists.sourceforge.jp > >> http://lists.sourceforge.jp/mailman/listinfo/ludia-users > >> > > > > _______________________________________________ > > Ludia-users mailing list > > Ludia-users @ lists.sourceforge.jp > > http://lists.sourceforge.jp/mailman/listinfo/ludia-users > > > > > > _______________________________________________ > Ludia-users mailing list > Ludia-users @ lists.sourceforge.jp > http://lists.sourceforge.jp/mailman/listinfo/ludia-users > From kanout @ nttdata.co.jp Thu Dec 13 18:24:39 2007 From: kanout @ nttdata.co.jp (kanout @ nttdata.co.jp) Date: Thu, 13 Dec 2007 18:24:39 +0900 Subject: [Ludia-users 150] Re: =?iso-2022-jp?b?GyRCSiM/dCROJUYhPCVWJWskS0JQJDkka0E0SjgbKEI=?= =?iso-2022-jp?b?GyRCOCE6dyRLJEQkJCRGGyhC?= References: <003601c83d2f$a2352bd0$c6c8020a@vapor><178CD7FD87EF4B4BB23F3D0B6C201D3F048F7869@MAILSV11.msg.nttdata.co.jp><003f01c83d33$48852190$c6c8020a@vapor><178CD7FD87EF4B4BB23F3D0B6C201D3F048F786D@MAILSV11.msg.nttdata.co.jp><005801c83d4f$769cfe10$c6c8020a@vapor><178CD7FD87EF4B4BB23F3D0B6C201D3F048F786F@MAILSV11.msg.nttdata.co.jp><005f01c83d5e$ddef8060$c6c8020a@vapor> <178CD7FD87EF4B4BB23F3D0B6C201D3F048F7871@MAILSV11.msg.nttdata.co.jp> Message-ID: 加納です。下記は間違いですね。 > select * from > (select * from table1 where data @@ 'test') AS t1, > (select * from table2 where data @@ 'test') AS t2 > WHERE t1.id = t2.id; これだと、「検索対象が"件名かつ本文"の場合」になります。 検索対象が"件名又は本文"の場合ということですから、 > > SELECT * FROM table1,table2 > > WHERE > > table1.id = table2.id AND > > (table1.data @@ 'TEST' or table2.data @@ 'TEST') 少なくとも論理的にはこれで正しいと思います。あとはプラ ンがどうかですが。 で、幸坂くんのアイデアを利活用すると、と思ったのですが、 複雑怪奇になりますね。 select * from (select * from table1 where data @@ 'test') AS t1 INNER JOIN table2 AS t2 ON t1.id = t2.id UNION select * from (select * from table2 where data @@ 'test') AS t2 INNER JOIN Table1 AS t1 ON t1.id = t2.id; だといかがでしょう?論理的には合ってます。たぶん・・・ 2回アクセスすることになるので、効率的とは言えませんが、 強制的に全文検索インデックスを使えていると思います。 蛇足ですが、旧形式の結合は、OUTER JOINを使用する際に 大幅に書き換えなければいけないため、JOIN演算子を使用 されることをお勧めします。旧形式でOUTER JOINを使おう とすると、Oracle方言に引っかかったりマルチプラット フォームでの弊害も多いです。 実は、FULL OUTER JOINでうまくいくかと思ったのですが、 うまくいかないことに気がつきました。そのため、JOIN演 算子を残しています。 FULL OUTER JOIN については、下記を参照ください。 http://www.postgresql.jp/document/pg825doc/html/queries-table-expressions.ht ml#QUERIES-FROM From sakamoto-t @ ma.dnes.nec.co.jp Thu Dec 13 18:49:44 2007 From: sakamoto-t @ ma.dnes.nec.co.jp (sakamoto) Date: Thu, 13 Dec 2007 18:49:44 +0900 Subject: [Ludia-users 151] Re: =?iso-2022-jp?b?GyRCMGwyc0xcJE44ITp3JCxDWSQkN28bKEI=?= References: <018001c80bee$26160b40$ae49440a@DNESsakata1> <178CD7FD87EF4B4BB23F3D0B6C201D3F02B71C39@MAILSV11.msg.nttdata.co.jp><044201c80c82$680a33c0$ae49440a@DNESsakata1> <47132B7A.8020705@nttdata.co.jp> Message-ID: <01f101c83d6d$7d4e4430$ae49440a@DNESsakata1> こんにちは、坂本です。 幸坂さん、加納さん、折角お返事いただいたのに、 返信出来ずに申し訳ありませんでした。 お返事兼ねて、現在の状況をお知らせします。 幸坂さんのご指摘にあった  1.*.SEN.i.c以外をキャッシュに乗せ  2.SELECT COUNT(*) FROM tab;を実施 を実施することで高速にアクセスできるようになったため、 これを実施することにしました。 キャッシュに乗せきれない場合は、効果薄いかも知れませんが、 改善できるケースがあるということで。 また、これを一定期間後にも自動で実施することで、 途中で、フラッシュされた場合にも備えることにしました。 加納さんのご指摘の、インデックスとデータの関係は、 目からうろこでした。 通常は、全件(今回は20万件)ヒットさせるようなことは無いと 思いますが、データの内容や検索の方法によっては、こういう ケースも許しているのが現状です。 最初にヒット件数のみ取得して、閾値以上の場合は、 警告メッセージを出して再検索させるということもやっていますが、 現状ではLudia のpgs2getnhits関数は、直前の検索を実行していないと ならないとか、更新が入ると正確な件数にならないとか、そのほか、 弊社PPの仕様的な面も大きく利用できないでいます。 #本件は一応解決したことにしておりますが、別件で、また  期待の動作をしない部分があり、それについては、別途ご連絡させて  いただきます。 > こんばんは、加納です。 > > 幸坂からの回答とは別に・・・ > > > > SELECT COUNT(*) FROM tab; > > →(SQL1)とします > > > > > SELECT COUNT(*) FROM tab WHERE col @@ '??????'; > > →(SQL2)とします > > > > [ケース1] マシン起動→SQL1→SQL2 > > SQL1,SQL2共に遅い。 > > > > [ケース2] マシン起動→SQL2→SQL1 > > SQL2は遅いが、SQL1は速い > > > > SQL2のパターンも、PostgreSQLのデータ参照しているということでしょうか。 > > とすれば、PostgreSQLもsennaもどちらも影響の原因になると > > いうことでしょうか。 > > SQL1のパターンも、PostgreSQLのテーブル部を参照します。 > もし、COUNT(*)はインデックススキャンだという認識でのお > 話であれば、それはPostgreSQLには当てはまりません。 > PostgreSQLはインデックスも追記型のため、データ部を参照 > しないと確実にその行が生きていることを保証できないため > です。(インデックスに無効フラグはあるが、無効フラグが > オフだからといって、有効とは限らない) > > SQL1では、プランを確認しないとなんともいえませんが、 > テーブルスキャンの可能性があります。その場合、シーケン > シャルアクセスです。 > > SQL2では、インデックス経由のアクセスですので、テーブル > はランダムアクセスです。SQL1 です。ケース2のSQL1だけ早いことの解釈にはなっていません > が。そのあたりはメモリとの兼ね合いのように思います。 > > 根本的には、ヒット件数を削減していただくことしか対処はな > いように思います。20万件全件ヒットのLudiaアクセスが必須 > だとしたら、かなりつらい要件です。 > > _______________________________________________ > Ludia-users mailing list > Ludia-users @ lists.sourceforge.jp > http://lists.sourceforge.jp/mailman/listinfo/ludia-users From ssenou @ techno-mark.co.jp Fri Dec 14 17:01:12 2007 From: ssenou @ techno-mark.co.jp (ssenou) Date: Fri, 14 Dec 2007 17:01:12 +0900 Subject: [Ludia-users 152] Re: =?iso-2022-jp?b?GyRCSiM/dCROJUYhPCVWJWskS0JQJDkka0E0SjgbKEI=?= =?iso-2022-jp?b?GyRCOCE6dyRLJEQkJCRGGyhC?= References: <003601c83d2f$a2352bd0$c6c8020a@vapor><178CD7FD87EF4B4BB23F3D0B6C201D3F048F7869@MAILSV11.msg.nttdata.co.jp><003f01c83d33$48852190$c6c8020a@vapor><178CD7FD87EF4B4BB23F3D0B6C201D3F048F786D@MAILSV11.msg.nttdata.co.jp><005801c83d4f$769cfe10$c6c8020a@vapor><178CD7FD87EF4B4BB23F3D0B6C201D3F048F786F@MAILSV11.msg.nttdata.co.jp><005f01c83d5e$ddef8060$c6c8020a@vapor><178CD7FD87EF4B4BB23F3D0B6C201D3F048F7871@MAILSV11.msg.nttdata.co.jp> Message-ID: <005901c83e27$7edf7700$c6c8020a@vapor> 瀬能です。 サンプルありがとうございます。 参考になりました。 また質問などがあった時はよろしくお願いします。 ----- Original Message ----- From: To: Sent: Thursday, December 13, 2007 6:24 PM Subject: [Ludia-users 150] Re: 複数のテーブルに対する全文検索について > 加納です。下記は間違いですね。 > >> select * from >> (select * from table1 where data @@ 'test') AS t1, >> (select * from table2 where data @@ 'test') AS t2 >> WHERE t1.id = t2.id; > > これだと、「検索対象が"件名かつ本文"の場合」になります。 > > 検索対象が"件名又は本文"の場合ということですから、 > >> > SELECT * FROM table1,table2 >> > WHERE >> > table1.id = table2.id AND >> > (table1.data @@ 'TEST' or table2.data @@ 'TEST') > > 少なくとも論理的にはこれで正しいと思います。あとはプラ > ンがどうかですが。 > > で、幸坂くんのアイデアを利活用すると、と思ったのですが、 > 複雑怪奇になりますね。 > > select * from > (select * from table1 where data @@ 'test') AS t1 > INNER JOIN > table2 AS t2 > ON t1.id = t2.id > UNION > select * from > (select * from table2 where data @@ 'test') AS t2 > INNER JOIN > Table1 AS t1 > ON t1.id = t2.id; > > だといかがでしょう?論理的には合ってます。たぶん・・・ > 2回アクセスすることになるので、効率的とは言えませんが、 > 強制的に全文検索インデックスを使えていると思います。 > > 蛇足ですが、旧形式の結合は、OUTER JOINを使用する際に > 大幅に書き換えなければいけないため、JOIN演算子を使用 > されることをお勧めします。旧形式でOUTER JOINを使おう > とすると、Oracle方言に引っかかったりマルチプラット > フォームでの弊害も多いです。 > > 実は、FULL OUTER JOINでうまくいくかと思ったのですが、 > うまくいかないことに気がつきました。そのため、JOIN演 > 算子を残しています。 > > FULL OUTER JOIN については、下記を参照ください。 > http://www.postgresql.jp/document/pg825doc/html/queries-table-expressions.ht > ml#QUERIES-FROM > > _______________________________________________ > Ludia-users mailing list > Ludia-users @ lists.sourceforge.jp > http://lists.sourceforge.jp/mailman/listinfo/ludia-users > > From kousakadi @ nttdata.co.jp Fri Dec 14 17:05:59 2007 From: kousakadi @ nttdata.co.jp (kousakadi @ nttdata.co.jp) Date: Fri, 14 Dec 2007 17:05:59 +0900 Subject: [Ludia-users 153] Ludia1.4.0windows Message-ID: <178CD7FD87EF4B4BB23F3D0B6C201D3F048F7876@MAILSV11.msg.nttdata.co.jp> 幸坂です。こんにちは。 Ludia1.4.0 windows版をリリースしました。 変更内容はLudia1.4.0 Linux版と同じです。 http://lists.sourceforge.jp/mailman/archives/ludia-users/2007-December/00014 0.html 不具合など気づきましたら、ご報告お願いします。 From yamamototomomi @ gmail.com Mon Dec 17 18:57:48 2007 From: yamamototomomi @ gmail.com (Tomomi Yamamoto) Date: Mon, 17 Dec 2007 18:57:48 +0900 Subject: [Ludia-users 154] =?iso-2022-jp?b?cGdzMmdldHNjb3JlGyRCJEc8aEZAJDckP0NNJCwlXiUkGyhC?= =?iso-2022-jp?b?GyRCJUolOSRLJEokaiReJDkhIxsoQg==?= Message-ID: 検索時にpgs2getscoreで取得した値をソートと表示する数値に利用しようとしているのですが、戻ってくる値が必ずマイナスの値になってしまいます。 どうも、検索単語を多く含んでいるレコードほどマイナスの数値が大きく、プラスマイナスが逆転している感じもうけます。 SQLでは単一のテーブルを使わず、いくつかのサブクエリを組み合わせてデータを取得しているのですが、pgs2getscore自体はサブクエリ内の単一テーブルに対して行っています。 どうすれば、正常な値をとれるようになるでしょうか? ご教授いただければ幸いです。 よろしくお願いします。 From kousakadi @ nttdata.co.jp Tue Dec 18 10:29:47 2007 From: kousakadi @ nttdata.co.jp (kousakadi @ nttdata.co.jp) Date: Tue, 18 Dec 2007 10:29:47 +0900 Subject: [Ludia-users 155] Re: =?iso-2022-jp?b?cGdzMmdldHNjb3JlGyRCJEc8aEZAJDckP0NNJCwbKEI=?= =?iso-2022-jp?b?GyRCJV4lJCVKJTkkSyRKJGokXiQ5ISMbKEI=?= References: Message-ID: <178CD7FD87EF4B4BB23F3D0B6C201D3F048F787B@MAILSV11.msg.nttdata.co.jp> 幸坂です。こんにちは。 もうちょっと詳細な情報を頂けますか? http://lists.sourceforge.jp/mailman/archives/ludia-users/2007-December/00014 1.html こんな感じで書いてもらえると助かります。 EXPLAINの結果が特に重要なので、忘れずに書いてください。 > -----Original Message----- > From: ludia-users-bounces @ lists.sourceforge.jp > [mailto:ludia-users-bounces @ lists.sourceforge.jp] On Behalf > Of Tomomi Yamamoto > Sent: Monday, December 17, 2007 6:58 PM > To: ludia-users @ lists.sourceforge.jp > Subject: [Ludia-users 154]pgs2getscoreで取得した値がマイナスになります。 > > 検索時にpgs2getscoreで取得した値をソートと表示する数値に利用しようとしてい るのですが、戻ってくる値が必ずマイナス > の値になってしまいます。 > > どうも、検索単語を多く含んでいるレコードほどマイナスの数値が大きく、プラス マイナスが逆転している感じもうけます。 > > SQLでは単一のテーブルを使わず、いくつかのサブクエリを組み合わせてデータを 取得しているのですが、pgs2getscore自 > 体はサブクエリ内の単一テーブルに対して行っています。 > > どうすれば、正常な値をとれるようになるでしょうか? > > ご教授いただければ幸いです。 > よろしくお願いします。 > > _______________________________________________ > Ludia-users mailing list > Ludia-users @ lists.sourceforge.jp > http://lists.sourceforge.jp/mailman/listinfo/ludia-users > From yamamototomomi @ gmail.com Tue Dec 18 13:25:07 2007 From: yamamototomomi @ gmail.com (Tomomi Yamamoto) Date: Tue, 18 Dec 2007 13:25:07 +0900 Subject: [Ludia-users 156] Re: =?iso-2022-jp?b?cGdzMmdldHNjb3JlGyRCJEc8aEZAJDckP0NNJCwbKEI=?= =?iso-2022-jp?b?GyRCJV4lJCVKJTkkSyRKJGokXiQ5ISMbKEI=?= In-Reply-To: <178CD7FD87EF4B4BB23F3D0B6C201D3F048F787B@MAILSV11.msg.nttdata.co.jp> References: <178CD7FD87EF4B4BB23F3D0B6C201D3F048F787B@MAILSV11.msg.nttdata.co.jp> Message-ID: 山本です。 すいません、当方の環境ですが、このような感じです。 ■環境 (1) CentOS 5 Ludia 1.4.0 (mecab-0.96、mecab-ipadic 2.7.0-20070801、mecab-java 0.96、mecab-jumandic 5.1-20070304、Senna 1.0.9) PostgreSQL 8.1.9 (2) MacOS 10.5 Ludia 1.4.0 (mecab-0.96、mecab-ipadic 2.7.0-20070801、mecab-java 0.96、mecab-jumandic 5.1-20070304、Senna 1.0.9) PostgreSQL 8.2.3 ■設定 [postgres.conf] custom_variable_classes = 'ludia' ludia.max_n_sort_result = 100000 ludia.enable_seqscan = on ludia.seqscan_flags = 1 ludia.sen_index_flags = 19 ludia.max_n_index_cache = 16 ludia.initial_n_segments = 1024 ■DB table1(構成) ・link_id int4 ・site_id int4 ・url varchar(255) ・title text ・description text ・fulltxt text ・indexdate date ・size real ・md5sum varchar(32) ・clickcnt int4 table2(構成) ・site_id int4 ・link_id int4 ・word text ・score int4 table3(構成) ・site_id int4 ・link_id int4 ・tag_id int4 ・id int4 ・tagword text table1(DATA) ・link_id = 6407 ・site_id = 5 ・url = "http://www.testtest.com/event001/03-d.html" ・title = "EVENT REPORT" ・description = "" ・fulltxt = "イベントリポート" ・indexdate = "2007-12-18" ・size = 4.16 ・md5sum = "b6ec4029f6a24fcd41875c266edc43e2" ・clickcnt = 0 table2(DATA) table3(DATA) ・site_id = 5 ・link_id = 6422 ・tag_id = 6 ・id = 0 ・tagword = "EVENT REPORT" table1(INDEX) ・fulltextb table2 ・fulltextb ■現象 select a.link_id , a.url , a.title , a.description , fulltxt , a.size , TO_CHAR(a.indexdate,'YYYY年MM月DD日') as indexdate , a.level , ((case when b.score is null then 1 else b.score end)+a.clickcnt) as score , (case when b.score is null then 1 else b.score end) as score_o , a.ludiascore from ( select link_id , site_id , url , title , description , fulltxt , indexdate , size , md5sum , visible , level , clickcnt , delflg , parenturl , pgs2getscore(ctid, 'idx_ngram_table1') as ludiascore from table1 a where ( ((a.fulltxt @@ 'イベント') or (a.title @@ 'イベント') or (a.description @@ 'イベント')) or a.link_id in ( select a.link_id from table2 a where (a.word @@ 'イベント') and a.site_id=5 ) ) and a.delflg=0 and a.site_id=5 ) a left join ( select a.link_id , sum(a.score) as score from ( select 'tag' as f , a.link_id , sum((case when b.score is null then 1 else b.score end)) as score from table3 a left join usr_1_tags b on a.tag_id=b.tag_id where (a.tagword @@ 'イベント') and a.site_id=b.site_id and a.site_id=5 group by a.link_id union select 'score' as f , a.link_id , sum((case when a.score is null then 1 else a.score end)) as score from table2 a where (a.word @@ 'イベント') and a.site_id=5 group by a.link_id ) a group by a.link_id ) b on a.link_id=b.link_id order by (case when b.score is null then 1 else b.score end)+a.clickcnt desc , (case when b.score is null then 1 else b.score end) desc , a.clickcnt desc , a.level asc , a.indexdate desc , a.size des と、実行すると、 「ludiascore」が「-21」や「-14」などの数値で戻ってきます。 データによっては+の数値で戻ってくることもあります。 07/12/18 に kousakadi @ nttdata.co.jp さんは書きました: > 幸坂です。こんにちは。 > > もうちょっと詳細な情報を頂けますか? > > http://lists.sourceforge.jp/mailman/archives/ludia-users/2007-December/00014 > 1.html > こんな感じで書いてもらえると助かります。 > EXPLAINの結果が特に重要なので、忘れずに書いてください。 > > > -----Original Message----- > > From: ludia-users-bounces @ lists.sourceforge.jp > > [mailto:ludia-users-bounces @ lists.sourceforge.jp] On Behalf > > Of Tomomi Yamamoto > > Sent: Monday, December 17, 2007 6:58 PM > > To: ludia-users @ lists.sourceforge.jp > > Subject: [Ludia-users 154]pgs2getscoreで取得した値がマイナスになります。 > > > > 検索時にpgs2getscoreで取得した値をソートと表示する数値に利用しようとしてい > るのですが、戻ってくる値が必ずマイナス > > の値になってしまいます。 > > > > どうも、検索単語を多く含んでいるレコードほどマイナスの数値が大きく、プラス > マイナスが逆転している感じもうけます。 > > > > SQLでは単一のテーブルを使わず、いくつかのサブクエリを組み合わせてデータを > 取得しているのですが、pgs2getscore自 > > 体はサブクエリ内の単一テーブルに対して行っています。 > > > > どうすれば、正常な値をとれるようになるでしょうか? > > > > ご教授いただければ幸いです。 > > よろしくお願いします。 > > From sakamoto-t @ ma.dnes.nec.co.jp Tue Dec 18 14:01:31 2007 From: sakamoto-t @ ma.dnes.nec.co.jp (sakamoto) Date: Tue, 18 Dec 2007 14:01:31 +0900 Subject: [Ludia-users 157] =?iso-2022-jp?b?GyRCJUchPCU/RWpGfjt+JEslYSViJWozTkpdJSglaSE8GyhC?= Message-ID: <00e501c84133$0e2f5660$dd48440a@DNESsakata2> こんにちは、坂本です。 Windows上で、次のようなシーケンスで大量にデータ投入を行っています。 (Ludia1.2+senna1.0.8) 1.全文検索インデックス1個を持った表1へデータを順次投入します。 2.インデックスサイズが約512MB近くになると、表1への   データ投入を終了し、同一の構造を持った表2を作成し、   表2へデータ投入を続けます。 3.表2もインデックスサイズが約512MB近くになると、次に   表3を作成し、表3へデータ投入を続けます。 4.このように1表の(1インデックスサイズ)をある程度抑えて、   順次表を追加していく形で大量データの投入を試みています。 ※1インデックスが2GBを超えると、メモリ確保できずにエラーと  なる件がありましたが、それを回避するために表を分割しています。  また、1インデックスが1GBを超えると更新時の性能が出ない  こともあり、切り替えの設定を低めにしています。 本処理を実行し続けると、途中で、エラーで落ちます。 実際のSQLシーケンスとしては、   BEGIN → INSERT (100件程度)→ COMMIT を繰り返しています。 Ludiaログの内容は、次の通りです。 2007-10-24 04:40:42 LOG: pgsenna2: |A| malloc fail (76836502)=00000000 (..\lib\inv.c:922) <9617> 2007-10-24 04:40:42 ERROR: pgsenna2: sen_index_upd failed while do_insert (1) 2007-10-24 04:40:42 STATEMENT: INSERT INTO T_CSV_000012 (SMGSEQ, PAGENO, DATA) VALUES(502724, 1, ' Ludia1.3.1でメモリの解放に関する修正を行ったということで、 これも確認しましたが、同じ場所で、同様に落ちます。 2007-10-27 14:09:12 LOG: pgsenna2: |A| malloc fail (76836502)=00000000 (..\lib\inv.c:922) <9619> 2007-10-27 14:09:12 ERROR: pgsenna2: sen_index_update failed 1,0 2007-10-27 14:09:12 STATEMENT: INSERT INTO T_CSV_000012 (SMGSEQ, PAGENO, DATA) VALUES(502724, 1, ' 少なくとも、COMMIT時にメモリも解放されて問題なく動作すると 考えているのですが、1APから実行することによる弊害があるのでしょうか。 合計は2GBを優に超えています。 ちなみに、エラー後、以降の処理を再実行すると正常に格納されます。 何か考えらること、良い対応方法は無いでしょうか。 From kousakadi @ nttdata.co.jp Tue Dec 18 14:57:38 2007 From: kousakadi @ nttdata.co.jp (kousakadi @ nttdata.co.jp) Date: Tue, 18 Dec 2007 14:57:38 +0900 Subject: [Ludia-users 158] Re: =?iso-2022-jp?b?GyRCJUchPCU/RWpGfjt+JEslYSViJWozTkpdJSgbKEI=?= =?iso-2022-jp?b?GyRCJWkhPBsoQg==?= References: <00e501c84133$0e2f5660$dd48440a@DNESsakata2> Message-ID: <178CD7FD87EF4B4BB23F3D0B6C201D3F048F787E@MAILSV11.msg.nttdata.co.jp> 幸坂です。こんにちは。 1プロセスのメモリ使用量が原因かもしれません。 max_n_index_cacheを小さい数字にすると、 問題が解決する可能性があります。 max_n_index_cacheは1プロセスが開けるインデックス数です。 この値を超えてインデックスオープンを試みると、 LRU方式でインデックスをクローズし(sen_index_close)、 Sennaのメモリを解放します。 以下の内容も参考にしてください。 http://lists.sourceforge.jp/mailman/archives/ludia-users/2007-October/000110 .html http://lists.sourceforge.jp/mailman/archives/ludia-users/2007-October/000123 .html > ちなみに、エラー後、以降の処理を再実行すると正常に格納されます。 エラーにより接続が切れて、全てのメモリが解放されたため、 正常に動作していると思われます。 > -----Original Message----- > From: ludia-users-bounces @ lists.sourceforge.jp > [mailto:ludia-users-bounces @ lists.sourceforge.jp] On Behalf > Of sakamoto > Sent: Tuesday, December 18, 2007 2:02 PM > To: ludia-users @ lists.sourceforge.jp > Subject: [Ludia-users 157]データ投入時にメモリ確保エラー > > こんにちは、坂本です。 > > Windows上で、次のようなシーケンスで大量にデータ投入を行っています。 > (Ludia1.2+senna1.0.8) > > 1.全文検索インデックス1個を持った表1へデータを順次投入します。 > 2.インデックスサイズが約512MB近くになると、表1への >   データ投入を終了し、同一の構造を持った表2を作成し、 >   表2へデータ投入を続けます。 > 3.表2もインデックスサイズが約512MB近くになると、次に >   表3を作成し、表3へデータ投入を続けます。 > 4.このように1表の(1インデックスサイズ)をある程度抑えて、 >   順次表を追加していく形で大量データの投入を試みています。 > > ※1インデックスが2GBを超えると、メモリ確保できずにエラーと >  なる件がありましたが、それを回避するために表を分割しています。 >  また、1インデックスが1GBを超えると更新時の性能が出ない >  こともあり、切り替えの設定を低めにしています。 > > 本処理を実行し続けると、途中で、エラーで落ちます。 > 実際のSQLシーケンスとしては、 >   BEGIN → INSERT (100件程度)→ COMMIT > を繰り返しています。 > > Ludiaログの内容は、次の通りです。 > > 2007-10-24 04:40:42 LOG: pgsenna2: |A| malloc fail > (76836502)=00000000 > (..\lib\inv.c:922) <9617> > 2007-10-24 04:40:42 ERROR: pgsenna2: sen_index_upd failed > while do_insert > (1) > 2007-10-24 04:40:42 STATEMENT: INSERT INTO T_CSV_000012 > (SMGSEQ, PAGENO, > DATA) VALUES(502724, 1, ' > > Ludia1.3.1でメモリの解放に関する修正を行ったということで、 > これも確認しましたが、同じ場所で、同様に落ちます。 > > 2007-10-27 14:09:12 LOG: pgsenna2: |A| malloc fail > (76836502)=00000000 > (..\lib\inv.c:922) <9619> > 2007-10-27 14:09:12 ERROR: pgsenna2: sen_index_update failed 1,0 > 2007-10-27 14:09:12 STATEMENT: INSERT INTO T_CSV_000012 > (SMGSEQ, PAGENO, > DATA) VALUES(502724, 1, ' > > 少なくとも、COMMIT時にメモリも解放されて問題なく動作すると > 考えているのですが、1APから実行することによる弊害があるのでしょうか。 > 合計は2GBを優に超えています。 > > ちなみに、エラー後、以降の処理を再実行すると正常に格納されます。 > > 何か考えらること、良い対応方法は無いでしょうか。 > > _______________________________________________ > Ludia-users mailing list > Ludia-users @ lists.sourceforge.jp > http://lists.sourceforge.jp/mailman/listinfo/ludia-users > From sakamoto-t @ ma.dnes.nec.co.jp Tue Dec 18 19:25:19 2007 From: sakamoto-t @ ma.dnes.nec.co.jp (sakamoto) Date: Tue, 18 Dec 2007 19:25:19 +0900 Subject: [Ludia-users 159] Re: =?iso-2022-jp?b?GyRCJUchPCU/RWpGfjt+JEslYSViJWozTkpdJSgbKEI=?= =?iso-2022-jp?b?GyRCJWkhPBsoQg==?= References: <00e501c84133$0e2f5660$dd48440a@DNESsakata2> <178CD7FD87EF4B4BB23F3D0B6C201D3F048F787E@MAILSV11.msg.nttdata.co.jp> Message-ID: <004b01c84160$4a31c260$dd48440a@DNESsakata2> 坂本です。 幸坂さん、ありがとうございます。 COMMITを切っても、sennaのインデックスは 解放されないということですね。 該当環境では、max_n_index_cacheを105に設定変更しています。 というのも、1インデックスが2Gを超えるとエラーになるので、 分割するようにしたのですが、参照する際には、それらを Viewを使って参照しているので、同時にsennaのインデックスを オープンする数が増えるなあ、ということで。 お話からすると、今回のケースでは、12個目のインデックスで エラーになっているので、それ以下に設定すれば、投入時の エラーは回避できるかも知れませんが、 参照時にmax_n_index_cacheのために同時にオープンできなくて、 または、max_n_index_cacheを増やしても、今度は、1プロセスの メモリ取得でエラーになりそうな雰囲気ですね。 現在、該当環境が無いので、参照系の確認ができず、 歯がゆいのですが、まず、max_n_index_cacheの設定変更で どうなるかの確認は行いたいと思います。 > 幸坂です。こんにちは。 > > 1プロセスのメモリ使用量が原因かもしれません。 > max_n_index_cacheを小さい数字にすると、 > 問題が解決する可能性があります。 > > max_n_index_cacheは1プロセスが開けるインデックス数です。 > この値を超えてインデックスオープンを試みると、 > LRU方式でインデックスをクローズし(sen_index_close)、 > Sennaのメモリを解放します。 > > 以下の内容も参考にしてください。 > http://lists.sourceforge.jp/mailman/archives/ludia-users/2007-October/000110 > .html > http://lists.sourceforge.jp/mailman/archives/ludia-users/2007-October/000123 > .html > >> ちなみに、エラー後、以降の処理を再実行すると正常に格納されます。 > エラーにより接続が切れて、全てのメモリが解放されたため、 > 正常に動作していると思われます。 > >> -----Original Message----- >> From: ludia-users-bounces @ lists.sourceforge.jp >> [mailto:ludia-users-bounces @ lists.sourceforge.jp] On Behalf >> Of sakamoto >> Sent: Tuesday, December 18, 2007 2:02 PM >> To: ludia-users @ lists.sourceforge.jp >> Subject: [Ludia-users 157]データ投入時にメモリ確保エラー >> >> こんにちは、坂本です。 >> >> Windows上で、次のようなシーケンスで大量にデータ投入を行っています。 >> (Ludia1.2+senna1.0.8) >> >> 1.全文検索インデックス1個を持った表1へデータを順次投入します。 >> 2.インデックスサイズが約512MB近くになると、表1への >>   データ投入を終了し、同一の構造を持った表2を作成し、 >>   表2へデータ投入を続けます。 >> 3.表2もインデックスサイズが約512MB近くになると、次に >>   表3を作成し、表3へデータ投入を続けます。 >> 4.このように1表の(1インデックスサイズ)をある程度抑えて、 >>   順次表を追加していく形で大量データの投入を試みています。 >> >> ※1インデックスが2GBを超えると、メモリ確保できずにエラーと >>  なる件がありましたが、それを回避するために表を分割しています。 >>  また、1インデックスが1GBを超えると更新時の性能が出ない >>  こともあり、切り替えの設定を低めにしています。 >> >> 本処理を実行し続けると、途中で、エラーで落ちます。 >> 実際のSQLシーケンスとしては、 >>   BEGIN → INSERT (100件程度)→ COMMIT >> を繰り返しています。 >> >> Ludiaログの内容は、次の通りです。 >> >> 2007-10-24 04:40:42 LOG: pgsenna2: |A| malloc fail >> (76836502)=00000000 >> (..\lib\inv.c:922) <9617> >> 2007-10-24 04:40:42 ERROR: pgsenna2: sen_index_upd failed >> while do_insert >> (1) >> 2007-10-24 04:40:42 STATEMENT: INSERT INTO T_CSV_000012 >> (SMGSEQ, PAGENO, >> DATA) VALUES(502724, 1, ' >> >> Ludia1.3.1でメモリの解放に関する修正を行ったということで、 >> これも確認しましたが、同じ場所で、同様に落ちます。 >> >> 2007-10-27 14:09:12 LOG: pgsenna2: |A| malloc fail >> (76836502)=00000000 >> (..\lib\inv.c:922) <9619> >> 2007-10-27 14:09:12 ERROR: pgsenna2: sen_index_update failed 1,0 >> 2007-10-27 14:09:12 STATEMENT: INSERT INTO T_CSV_000012 >> (SMGSEQ, PAGENO, >> DATA) VALUES(502724, 1, ' >> >> 少なくとも、COMMIT時にメモリも解放されて問題なく動作すると >> 考えているのですが、1APから実行することによる弊害があるのでしょうか。 >> 合計は2GBを優に超えています。 >> >> ちなみに、エラー後、以降の処理を再実行すると正常に格納されます。 >> >> 何か考えらること、良い対応方法は無いでしょうか。 >> >> _______________________________________________ >> Ludia-users mailing list >> Ludia-users @ lists.sourceforge.jp >> http://lists.sourceforge.jp/mailman/listinfo/ludia-users >> > > _______________________________________________ > Ludia-users mailing list > Ludia-users @ lists.sourceforge.jp > http://lists.sourceforge.jp/mailman/listinfo/ludia-users From yamamototomomi @ gmail.com Thu Dec 20 17:06:48 2007 From: yamamototomomi @ gmail.com (Tomomi Yamamoto) Date: Thu, 20 Dec 2007 17:06:48 +0900 Subject: [Ludia-users 160] =?iso-2022-jp?b?GyRCJFIkaSQsJEokRyRiJSslPyUrJUokRyRiOCE6dyQ3GyhC?= =?iso-2022-jp?b?GyRCJD8kJCRzJEckOSQsISYhJiEmGyhC?= Message-ID: 山本です。 Ludiaになるのか、Senna・MeCabになるのか、不明なため失礼いたします。 データベース上に登録してあるテキストから、指定した文字列がひらがなでもカタカナでも引っかかるようにと考えています。 (例えば、「イケメン」でも「いけめん」でも、文章中の「イケメン」を引っぱってこれるなど) このような曖昧な検索を行わせるためには、何か設定が必要なのでしょうか? 初心者的な質問で申し訳ありません。 ご教授いただければ幸いです。 【環境】 Ludia 1.4.0 (mecab-0.96、mecab-ipadic 2.7.0-20070801、mecab-java 0.96、mecab-jumandic 5.1-20070304、Senna 1.0.9) PostgreSQL 8.1.9 【設定】 [postgres.conf] custom_variable_classes = 'ludia' ludia.max_n_sort_result = 100000 ludia.enable_seqscan = on ludia.seqscan_flags = 1 ludia.sen_index_flags = 19 ludia.max_n_index_cache = 16 ludia.initial_n_segments = 1024 From kousakadi @ nttdata.co.jp Fri Dec 21 09:08:52 2007 From: kousakadi @ nttdata.co.jp (kousakadi @ nttdata.co.jp) Date: Fri, 21 Dec 2007 09:08:52 +0900 Subject: [Ludia-users 161] Re: =?iso-2022-jp?b?GyRCJFIkaSQsJEokRyRiJSslPyUrJUokRyRiOCEbKEI=?= =?iso-2022-jp?b?GyRCOnckNyQ/JCQkcyRHJDkkLCEmISYhJhsoQg==?= References: Message-ID: <178CD7FD87EF4B4BB23F3D0B6C201D3F048F7899@MAILSV11.msg.nttdata.co.jp> 幸坂です。こんにちは。 create function kata2hira (text) returns text as 'select translate($1, ''アイウ(略)ヲン'', ''あいう(略)をん'')' language sql immutable; create index idx on tab using fulltextb(kata2hira(col)); select * from tab where kata2hira(col) @@ kata2hira('イケメン'); とすればカタカナが全てひらがなに変換されて、 山本さんの意図した検索が可能になります。 (略)は全てのカタカナ・ひらがなが入ります。 形態素(fulltext)はあまり意味がなくなるので、 N-gramを使う必要があります。 試してみてください。 > -----Original Message----- > From: ludia-users-bounces @ lists.sourceforge.jp > [mailto:ludia-users-bounces @ lists.sourceforge.jp] On Behalf > Of Tomomi Yamamoto > Sent: Thursday, December 20, 2007 5:07 PM > To: ludia-users @ lists.sourceforge.jp > Subject: [Ludia-users 160]ひらがなでもカタカナでも検索したいんですが・・・ > > 山本です。 > > Ludiaになるのか、Senna・MeCabになるのか、不明なため失礼いたします。 > > データベース上に登録してあるテキストから、指定した文字列がひらがなでもカタ カナでも引っかかるようにと考えています。 > (例えば、「イケメン」でも「いけめん」でも、文章中の「イケメン」を引っぱっ てこれるなど) > > このような曖昧な検索を行わせるためには、何か設定が必要なのでしょうか? > > 初心者的な質問で申し訳ありません。 > ご教授いただければ幸いです。 > > 【環境】 > Ludia 1.4.0 > (mecab-0.96、mecab-ipadic 2.7.0-20070801、mecab-java > 0.96、mecab-jumandic 5.1-20070304、Senna 1.0.9) > PostgreSQL 8.1.9 > > 【設定】 > [postgres.conf] > custom_variable_classes = 'ludia' > ludia.max_n_sort_result = 100000 > ludia.enable_seqscan = on > ludia.seqscan_flags = 1 > ludia.sen_index_flags = 19 > ludia.max_n_index_cache = 16 > ludia.initial_n_segments = 1024 > > _______________________________________________ > Ludia-users mailing list > Ludia-users @ lists.sourceforge.jp > http://lists.sourceforge.jp/mailman/listinfo/ludia-users > From yamamototomomi @ gmail.com Sun Dec 23 22:41:23 2007 From: yamamototomomi @ gmail.com (Tomomi Yamamoto) Date: Sun, 23 Dec 2007 22:41:23 +0900 Subject: [Ludia-users 162] Re: =?iso-2022-jp?b?GyRCJFIkaSQsJEokRyRiJSslPyUrJUokRyRiOCEbKEI=?= =?iso-2022-jp?b?GyRCOnckNyQ/JCQkcyRHJDkkLCEmISYhJhsoQg==?= In-Reply-To: <178CD7FD87EF4B4BB23F3D0B6C201D3F048F7899@MAILSV11.msg.nttdata.co.jp> References: <178CD7FD87EF4B4BB23F3D0B6C201D3F048F7899@MAILSV11.msg.nttdata.co.jp> Message-ID: 幸坂さん ありがとうございます。なるほどですね。 これって漢字交じりや複数のカラムを対象にしたインデックスでも大丈夫なのでしょうか? やってみます。 07/12/21 に kousakadi @ nttdata.co.jp さんは書きました: > 幸坂です。こんにちは。 > > create function kata2hira (text) returns text as > 'select translate($1, ''アイウ(略)ヲン'', ''あいう(略)をん'')' > language sql immutable; > > create index idx on tab using fulltextb(kata2hira(col)); > > select * from tab where kata2hira(col) @@ kata2hira('イケメン'); > > とすればカタカナが全てひらがなに変換されて、 > 山本さんの意図した検索が可能になります。 > (略)は全てのカタカナ・ひらがなが入ります。 > > 形態素(fulltext)はあまり意味がなくなるので、 > N-gramを使う必要があります。 > > 試してみてください。 > > > -----Original Message----- > > From: ludia-users-bounces @ lists.sourceforge.jp > > [mailto:ludia-users-bounces @ lists.sourceforge.jp] On Behalf > > Of Tomomi Yamamoto > > Sent: Thursday, December 20, 2007 5:07 PM > > To: ludia-users @ lists.sourceforge.jp > > Subject: [Ludia-users 160]ひらがなでもカタカナでも検索したいんですが・・・ > > > > 山本です。 > > > > Ludiaになるのか、Senna・MeCabになるのか、不明なため失礼いたします。 > > > > データベース上に登録してあるテキストから、指定した文字列がひらがなでもカタ > カナでも引っかかるようにと考えています。 > > (例えば、「イケメン」でも「いけめん」でも、文章中の「イケメン」を引っぱっ > てこれるなど) > > > > このような曖昧な検索を行わせるためには、何か設定が必要なのでしょうか? > > > > 初心者的な質問で申し訳ありません。 > > ご教授いただければ幸いです。 > > > > 【環境】 > > Ludia 1.4.0 > > (mecab-0.96、mecab-ipadic 2.7.0-20070801、mecab-java > > 0.96、mecab-jumandic 5.1-20070304、Senna 1.0.9) > > PostgreSQL 8.1.9 > > > > 【設定】 > > [postgres.conf] > > custom_variable_classes = 'ludia' > > ludia.max_n_sort_result = 100000 > > ludia.enable_seqscan = on > > ludia.seqscan_flags = 1 > > ludia.sen_index_flags = 19 > > ludia.max_n_index_cache = 16 > > ludia.initial_n_segments = 1024 > > From sakamoto-t @ ma.dnes.nec.co.jp Wed Dec 26 15:02:10 2007 From: sakamoto-t @ ma.dnes.nec.co.jp (sakamoto) Date: Wed, 26 Dec 2007 15:02:10 +0900 Subject: [Ludia-users 163] Re: =?iso-2022-jp?b?GyRCJUchPCU/RWpGfjt+JEslYSViJWozTkpdJSgbKEI=?= =?iso-2022-jp?b?GyRCJWkhPBsoQg==?= References: <00e501c84133$0e2f5660$dd48440a@DNESsakata2><178CD7FD87EF4B4BB23F3D0B6C201D3F048F787E@MAILSV11.msg.nttdata.co.jp> <004b01c84160$4a31c260$dd48440a@DNESsakata2> Message-ID: <009e01c84784$da452980$dd48440a@DNESsakata2> こんにちは、坂本です。 下記の件、追加検証してみました。 max_n_index_cacheを5に変更してみたところ、インデックスがこの数を 越えると解放しているようで、評価予定の件数(50万件)を 格納することができました。 この時、sennaのインデックスは16個できていました。 また、この16個をまとめてViewにして検索したところ、予想通り、 max_n_index_cache=5の時は、 ERROR: pgsenna2: inconsistent scan, or max_n_index_cache is too small でエラーになり、 max_n_index_cache=16に設定すると、検索は正常終了しました。 ということから判断すると、1プロセスからのインデックス作成時に、 sennaのインデックスを解放しながら実行できれば、何とか なりそうなのですが、そのように、明示的にsennaインデックスを 解放する方法はあるでしょうか。 それと、もう一点、気になった点があるので、確認させていただきたいのですが、 SELECT col1 FROM V_View WHERE col2 @@ '黒' ;  (V_Viewは同一フォーマットの表を16表を結合している) はmax_n_index_cache=16で検索できましたが、 SELECT col1 FROM V_View WHERE col2 @@ '黒' INTERSECT SELECT col1 FROM V_View WHERE col2 @@ '白' ; はmax_n_index_cache=16では  ERROR: pgsenna2: inconsistent scan, or max_n_index_cache is too small のエラーとなり、max_n_index_cache=32 では正常終了しました。 同一インデックスでも、同一SQLで2度登場する場合、別カウントされている ということになるでしょうか? > 坂本です。 > > 幸坂さん、ありがとうございます。 > > COMMITを切っても、sennaのインデックスは > 解放されないということですね。 > > 該当環境では、max_n_index_cacheを105に設定変更しています。 > というのも、1インデックスが2Gを超えるとエラーになるので、 > 分割するようにしたのですが、参照する際には、それらを > Viewを使って参照しているので、同時にsennaのインデックスを > オープンする数が増えるなあ、ということで。 > > お話からすると、今回のケースでは、12個目のインデックスで > エラーになっているので、それ以下に設定すれば、投入時の > エラーは回避できるかも知れませんが、 > 参照時にmax_n_index_cacheのために同時にオープンできなくて、 > または、max_n_index_cacheを増やしても、今度は、1プロセスの > メモリ取得でエラーになりそうな雰囲気ですね。 > > 現在、該当環境が無いので、参照系の確認ができず、 > 歯がゆいのですが、まず、max_n_index_cacheの設定変更で > どうなるかの確認は行いたいと思います。 > > >> 幸坂です。こんにちは。 >> >> 1プロセスのメモリ使用量が原因かもしれません。 >> max_n_index_cacheを小さい数字にすると、 >> 問題が解決する可能性があります。 >> >> max_n_index_cacheは1プロセスが開けるインデックス数です。 >> この値を超えてインデックスオープンを試みると、 >> LRU方式でインデックスをクローズし(sen_index_close)、 >> Sennaのメモリを解放します。 >> >> 以下の内容も参考にしてください。 >> http://lists.sourceforge.jp/mailman/archives/ludia-users/2007-October/000110 >> .html >> http://lists.sourceforge.jp/mailman/archives/ludia-users/2007-October/000123 >> .html >> >>> ちなみに、エラー後、以降の処理を再実行すると正常に格納されます。 >> エラーにより接続が切れて、全てのメモリが解放されたため、 >> 正常に動作していると思われます。 >> >>> -----Original Message----- >>> From: ludia-users-bounces @ lists.sourceforge.jp >>> [mailto:ludia-users-bounces @ lists.sourceforge.jp] On Behalf >>> Of sakamoto >>> Sent: Tuesday, December 18, 2007 2:02 PM >>> To: ludia-users @ lists.sourceforge.jp >>> Subject: [Ludia-users 157]データ投入時にメモリ確保エラー >>> >>> こんにちは、坂本です。 >>> >>> Windows上で、次のようなシーケンスで大量にデータ投入を行っています。 >>> (Ludia1.2+senna1.0.8) >>> >>> 1.全文検索インデックス1個を持った表1へデータを順次投入します。 >>> 2.インデックスサイズが約512MB近くになると、表1への >>>   データ投入を終了し、同一の構造を持った表2を作成し、 >>>   表2へデータ投入を続けます。 >>> 3.表2もインデックスサイズが約512MB近くになると、次に >>>   表3を作成し、表3へデータ投入を続けます。 >>> 4.このように1表の(1インデックスサイズ)をある程度抑えて、 >>>   順次表を追加していく形で大量データの投入を試みています。 >>> >>> ※1インデックスが2GBを超えると、メモリ確保できずにエラーと >>>  なる件がありましたが、それを回避するために表を分割しています。 >>>  また、1インデックスが1GBを超えると更新時の性能が出ない >>>  こともあり、切り替えの設定を低めにしています。 >>> >>> 本処理を実行し続けると、途中で、エラーで落ちます。 >>> 実際のSQLシーケンスとしては、 >>>   BEGIN → INSERT (100件程度)→ COMMIT >>> を繰り返しています。 >>> >>> Ludiaログの内容は、次の通りです。 >>> >>> 2007-10-24 04:40:42 LOG: pgsenna2: |A| malloc fail >>> (76836502)=00000000 >>> (..\lib\inv.c:922) <9617> >>> 2007-10-24 04:40:42 ERROR: pgsenna2: sen_index_upd failed >>> while do_insert >>> (1) >>> 2007-10-24 04:40:42 STATEMENT: INSERT INTO T_CSV_000012 >>> (SMGSEQ, PAGENO, >>> DATA) VALUES(502724, 1, ' >>> >>> Ludia1.3.1でメモリの解放に関する修正を行ったということで、 >>> これも確認しましたが、同じ場所で、同様に落ちます。 >>> >>> 2007-10-27 14:09:12 LOG: pgsenna2: |A| malloc fail >>> (76836502)=00000000 >>> (..\lib\inv.c:922) <9619> >>> 2007-10-27 14:09:12 ERROR: pgsenna2: sen_index_update failed 1,0 >>> 2007-10-27 14:09:12 STATEMENT: INSERT INTO T_CSV_000012 >>> (SMGSEQ, PAGENO, >>> DATA) VALUES(502724, 1, ' >>> >>> 少なくとも、COMMIT時にメモリも解放されて問題なく動作すると >>> 考えているのですが、1APから実行することによる弊害があるのでしょうか。 >>> 合計は2GBを優に超えています。 >>> >>> ちなみに、エラー後、以降の処理を再実行すると正常に格納されます。 >>> >>> 何か考えらること、良い対応方法は無いでしょうか。 >>> >>> _______________________________________________ >>> Ludia-users mailing list >>> Ludia-users @ lists.sourceforge.jp >>> http://lists.sourceforge.jp/mailman/listinfo/ludia-users >>> >> >> _______________________________________________ >> Ludia-users mailing list >> Ludia-users @ lists.sourceforge.jp >> http://lists.sourceforge.jp/mailman/listinfo/ludia-users > > _______________________________________________ > Ludia-users mailing list > Ludia-users @ lists.sourceforge.jp > http://lists.sourceforge.jp/mailman/listinfo/ludia-users From kousakadi @ nttdata.co.jp Thu Dec 27 14:26:21 2007 From: kousakadi @ nttdata.co.jp (kousakadi @ nttdata.co.jp) Date: Thu, 27 Dec 2007 14:26:21 +0900 Subject: [Ludia-users 164] Re: =?iso-2022-jp?b?GyRCJUchPCU/RWpGfjt+JEslYSViJWozTkpdJSgbKEI=?= =?iso-2022-jp?b?GyRCJWkhPBsoQg==?= References: <00e501c84133$0e2f5660$dd48440a@DNESsakata2><178CD7FD87EF4B4BB23F3D0B6C201D3F048F787E@MAILSV11.msg.nttdata.co.jp><004b01c84160$4a31c260$dd48440a@DNESsakata2> <009e01c84784$da452980$dd48440a@DNESsakata2> Message-ID: <178CD7FD87EF4B4BB23F3D0B6C201D3F048F78AC@MAILSV11.msg.nttdata.co.jp> 幸坂です。こんにちは。 > また、この16個をまとめてViewにして検索したところ、予想通り、 > max_n_index_cache=5の時は、 > ERROR: pgsenna2: inconsistent scan, or max_n_index_cache is too small 1クエリ内でmax_n_index_cacheより多くのインデックスを利用すると、 エラーとなります。 この事象については、改良しようと思っているのですが、 max_n_index_cacheを大きくするという解決方法があり、 改修範囲も大きい事から、優先順位を下げています。 しかし、坂本さんの例もあるので、考え直した方が良さそうですね。 検討します。 > なりそうなのですが、そのように、明示的にsennaインデックスを > 解放する方法はあるでしょうか。 現状、明示的にSennaインデックスを解放する方法はありません。 接続を切れば解放できますが・・・。 > 同一インデックスでも、同一SQLで2度登場する場合、別カウントされている > ということになるでしょうか? バグが存在しました。 1クエリ内で使用するインデックス数=max_n_index_cacheで、 かつ、1クエリ内で同じインデックスを2回以上使用すると、 このバグが発生する場合があります。 WHERE col2 @@ '黒' AND col2 @@ '白'; のように、 単純にANDやORで繋げた場合は発生しません。 Ludiaの次のバージョンで修正します。 現状では、max_n_index_cacheを1大きい値(今回の場合17)に設定すると、 エラーにならないはずです。 以上です。 > -----Original Message----- > From: ludia-users-bounces @ lists.sourceforge.jp > [mailto:ludia-users-bounces @ lists.sourceforge.jp] On Behalf > Of sakamoto > Sent: Wednesday, December 26, 2007 3:02 PM > To: ludia-users @ lists.sourceforge.jp > Subject: [Ludia-users 163] Re:データ投入時にメモリ確保エラー > > こんにちは、坂本です。 > > 下記の件、追加検証してみました。 > > max_n_index_cacheを5に変更してみたところ、インデックスがこの数を > 越えると解放しているようで、評価予定の件数(50万件)を > 格納することができました。 > この時、sennaのインデックスは16個できていました。 > > また、この16個をまとめてViewにして検索したところ、予想通り、 > max_n_index_cache=5の時は、 > ERROR: pgsenna2: inconsistent scan, or max_n_index_cache is too small > でエラーになり、 > max_n_index_cache=16に設定すると、検索は正常終了しました。 > > ということから判断すると、1プロセスからのインデックス作成時に、 > sennaのインデックスを解放しながら実行できれば、何とか > なりそうなのですが、そのように、明示的にsennaインデックスを > 解放する方法はあるでしょうか。 > > それと、もう一点、気になった点があるので、確認させていただきたいのですが、 > > SELECT col1 FROM V_View WHERE col2 @@ '黒' ; >  (V_Viewは同一フォーマットの表を16表を結合している) > はmax_n_index_cache=16で検索できましたが、 > SELECT col1 FROM V_View WHERE col2 @@ '黒' INTERSECT > SELECT col1 FROM V_View WHERE col2 @@ '白' ; > はmax_n_index_cache=16では  > ERROR: pgsenna2: inconsistent scan, or max_n_index_cache is too small > のエラーとなり、max_n_index_cache=32 では正常終了しました。 > 同一インデックスでも、同一SQLで2度登場する場合、別カウントされている > ということになるでしょうか? > > > > > 坂本です。 > > > > 幸坂さん、ありがとうございます。 > > > > COMMITを切っても、sennaのインデックスは > > 解放されないということですね。 > > > > 該当環境では、max_n_index_cacheを105に設定変更しています。 > > というのも、1インデックスが2Gを超えるとエラーになるので、 > > 分割するようにしたのですが、参照する際には、それらを > > Viewを使って参照しているので、同時にsennaのインデックスを > > オープンする数が増えるなあ、ということで。 > > > > お話からすると、今回のケースでは、12個目のインデックスで > > エラーになっているので、それ以下に設定すれば、投入時の > > エラーは回避できるかも知れませんが、 > > 参照時にmax_n_index_cacheのために同時にオープンできなくて、 > > または、max_n_index_cacheを増やしても、今度は、1プロセスの > > メモリ取得でエラーになりそうな雰囲気ですね。 > > > > 現在、該当環境が無いので、参照系の確認ができず、 > > 歯がゆいのですが、まず、max_n_index_cacheの設定変更で > > どうなるかの確認は行いたいと思います。 > > > > > >> 幸坂です。こんにちは。 > >> > >> 1プロセスのメモリ使用量が原因かもしれません。 > >> max_n_index_cacheを小さい数字にすると、 > >> 問題が解決する可能性があります。 > >> > >> max_n_index_cacheは1プロセスが開けるインデックス数です。 > >> この値を超えてインデックスオープンを試みると、 > >> LRU方式でインデックスをクローズし(sen_index_close)、 > >> Sennaのメモリを解放します。 > >> > >> 以下の内容も参考にしてください。 > >> > http://lists.sourceforge.jp/mailman/archives/ludia-users/2007- > October/000110 > >> .html > >> > http://lists.sourceforge.jp/mailman/archives/ludia-users/2007- > October/000123 > >> .html > >> > >>> ちなみに、エラー後、以降の処理を再実行すると正常に格納されます。 > >> エラーにより接続が切れて、全てのメモリが解放されたため、 > >> 正常に動作していると思われます。 > >> > >>> -----Original Message----- > >>> From: ludia-users-bounces @ lists.sourceforge.jp > >>> [mailto:ludia-users-bounces @ lists.sourceforge.jp] On Behalf > >>> Of sakamoto > >>> Sent: Tuesday, December 18, 2007 2:02 PM > >>> To: ludia-users @ lists.sourceforge.jp > >>> Subject: [Ludia-users 157]データ投入時にメモリ確保エラー > >>> > >>> こんにちは、坂本です。 > >>> > >>> Windows上で、次のようなシーケンスで大量にデータ投入を行っています。 > >>> (Ludia1.2+senna1.0.8) > >>> > >>> 1.全文検索インデックス1個を持った表1へデータを順次投入します。 > >>> 2.インデックスサイズが約512MB近くになると、表1への > >>>   データ投入を終了し、同一の構造を持った表2を作成し、 > >>>   表2へデータ投入を続けます。 > >>> 3.表2もインデックスサイズが約512MB近くになると、次に > >>>   表3を作成し、表3へデータ投入を続けます。 > >>> 4.このように1表の(1インデックスサイズ)をある程度抑えて、 > >>>   順次表を追加していく形で大量データの投入を試みています。 > >>> > >>> ※1インデックスが2GBを超えると、メモリ確保できずにエラーと > >>>  なる件がありましたが、それを回避するために表を分割しています。 > >>>  また、1インデックスが1GBを超えると更新時の性能が出ない > >>>  こともあり、切り替えの設定を低めにしています。 > >>> > >>> 本処理を実行し続けると、途中で、エラーで落ちます。 > >>> 実際のSQLシーケンスとしては、 > >>>   BEGIN → INSERT (100件程度)→ COMMIT > >>> を繰り返しています。 > >>> > >>> Ludiaログの内容は、次の通りです。 > >>> > >>> 2007-10-24 04:40:42 LOG: pgsenna2: |A| malloc fail > >>> (76836502)=00000000 > >>> (..\lib\inv.c:922) <9617> > >>> 2007-10-24 04:40:42 ERROR: pgsenna2: sen_index_upd failed > >>> while do_insert > >>> (1) > >>> 2007-10-24 04:40:42 STATEMENT: INSERT INTO T_CSV_000012 > >>> (SMGSEQ, PAGENO, > >>> DATA) VALUES(502724, 1, ' > >>> > >>> Ludia1.3.1でメモリの解放に関する修正を行ったということで、 > >>> これも確認しましたが、同じ場所で、同様に落ちます。 > >>> > >>> 2007-10-27 14:09:12 LOG: pgsenna2: |A| malloc fail > >>> (76836502)=00000000 > >>> (..\lib\inv.c:922) <9619> > >>> 2007-10-27 14:09:12 ERROR: pgsenna2: sen_index_update failed 1,0 > >>> 2007-10-27 14:09:12 STATEMENT: INSERT INTO T_CSV_000012 > >>> (SMGSEQ, PAGENO, > >>> DATA) VALUES(502724, 1, ' > >>> > >>> 少なくとも、COMMIT時にメモリも解放されて問題なく動作すると > >>> 考えているのですが、1APから実行することによる弊害があるのでしょうか。 > >>> 合計は2GBを優に超えています。 > >>> > >>> ちなみに、エラー後、以降の処理を再実行すると正常に格納されます。 > >>> > >>> 何か考えらること、良い対応方法は無いでしょうか。 > >>> > >>> _______________________________________________ > >>> Ludia-users mailing list > >>> Ludia-users @ lists.sourceforge.jp > >>> http://lists.sourceforge.jp/mailman/listinfo/ludia-users > >>> > >> > >> _______________________________________________ > >> Ludia-users mailing list > >> Ludia-users @ lists.sourceforge.jp > >> http://lists.sourceforge.jp/mailman/listinfo/ludia-users > > > > _______________________________________________ > > Ludia-users mailing list > > Ludia-users @ lists.sourceforge.jp > > http://lists.sourceforge.jp/mailman/listinfo/ludia-users > > _______________________________________________ > Ludia-users mailing list > Ludia-users @ lists.sourceforge.jp > http://lists.sourceforge.jp/mailman/listinfo/ludia-users > From sakamoto-t @ ma.dnes.nec.co.jp Thu Dec 27 20:36:00 2007 From: sakamoto-t @ ma.dnes.nec.co.jp (sakamoto) Date: Thu, 27 Dec 2007 20:36:00 +0900 Subject: [Ludia-users 165] Re: =?iso-2022-jp?b?GyRCJUchPCU/RWpGfjt+JEslYSViJWozTkpdJSgbKEI=?= =?iso-2022-jp?b?GyRCJWkhPBsoQg==?= References: <00e501c84133$0e2f5660$dd48440a@DNESsakata2><178CD7FD87EF4B4BB23F3D0B6C201D3F048F787E@MAILSV11.msg.nttdata.co.jp><004b01c84160$4a31c260$dd48440a@DNESsakata2><009e01c84784$da452980$dd48440a@DNESsakata2> <178CD7FD87EF4B4BB23F3D0B6C201D3F048F78AC@MAILSV11.msg.nttdata.co.jp> Message-ID: <012001c8487c$a7cf62b0$dd48440a@DNESsakata2> 坂本です。 幸坂さん、ありがとうございます。 後半部のバグの件、SQLの組み方にも問題があるので、 そこは修正したいと考えていますので、致命的な問題には なっていないのですが、 前半部の明示的にSennaインデックスを解放する方法が無いのは、 残念でした。 プロセスを落とさなくとも、接続を切れば良いということであれば、 こちらサイドで対応できるかなということで、手を入れてみたいと 思っています。 よろしくお願いいたします。 > 幸坂です。こんにちは。 > >> また、この16個をまとめてViewにして検索したところ、予想通り、 >> max_n_index_cache=5の時は、 >> ERROR: pgsenna2: inconsistent scan, or max_n_index_cache is too small > 1クエリ内でmax_n_index_cacheより多くのインデックスを利用すると、 > エラーとなります。 > この事象については、改良しようと思っているのですが、 > max_n_index_cacheを大きくするという解決方法があり、 > 改修範囲も大きい事から、優先順位を下げています。 > しかし、坂本さんの例もあるので、考え直した方が良さそうですね。 > 検討します。 > >> なりそうなのですが、そのように、明示的にsennaインデックスを >> 解放する方法はあるでしょうか。 > 現状、明示的にSennaインデックスを解放する方法はありません。 > 接続を切れば解放できますが・・・。 > >> 同一インデックスでも、同一SQLで2度登場する場合、別カウントされている >> ということになるでしょうか? > バグが存在しました。 > 1クエリ内で使用するインデックス数=max_n_index_cacheで、 > かつ、1クエリ内で同じインデックスを2回以上使用すると、 > このバグが発生する場合があります。 > WHERE col2 @@ '黒' AND col2 @@ '白'; のように、 > 単純にANDやORで繋げた場合は発生しません。 > > Ludiaの次のバージョンで修正します。 > > 現状では、max_n_index_cacheを1大きい値(今回の場合17)に設定すると、 > エラーにならないはずです。 > > 以上です。 > >> -----Original Message----- >> From: ludia-users-bounces @ lists.sourceforge.jp >> [mailto:ludia-users-bounces @ lists.sourceforge.jp] On Behalf >> Of sakamoto >> Sent: Wednesday, December 26, 2007 3:02 PM >> To: ludia-users @ lists.sourceforge.jp >> Subject: [Ludia-users 163] Re:データ投入時にメモリ確保エラー >> >> こんにちは、坂本です。 >> >> 下記の件、追加検証してみました。 >> >> max_n_index_cacheを5に変更してみたところ、インデックスがこの数を >> 越えると解放しているようで、評価予定の件数(50万件)を >> 格納することができました。 >> この時、sennaのインデックスは16個できていました。 >> >> また、この16個をまとめてViewにして検索したところ、予想通り、 >> max_n_index_cache=5の時は、 >> ERROR: pgsenna2: inconsistent scan, or max_n_index_cache is too small >> でエラーになり、 >> max_n_index_cache=16に設定すると、検索は正常終了しました。 >> >> ということから判断すると、1プロセスからのインデックス作成時に、 >> sennaのインデックスを解放しながら実行できれば、何とか >> なりそうなのですが、そのように、明示的にsennaインデックスを >> 解放する方法はあるでしょうか。 >> >> それと、もう一点、気になった点があるので、確認させていただきたいのですが、 >> >> >> SELECT col1 FROM V_View WHERE col2 @@ '黒' ; >>  (V_Viewは同一フォーマットの表を16表を結合している) >> はmax_n_index_cache=16で検索できましたが、 >> SELECT col1 FROM V_View WHERE col2 @@ '黒' INTERSECT >> SELECT col1 FROM V_View WHERE col2 @@ '白' ; >> はmax_n_index_cache=16では  >> ERROR: pgsenna2: inconsistent scan, or max_n_index_cache is too small >> のエラーとなり、max_n_index_cache=32 では正常終了しました。 >> 同一インデックスでも、同一SQLで2度登場する場合、別カウントされている >> ということになるでしょうか? >> >> >> >> > 坂本です。 >> > >> > 幸坂さん、ありがとうございます。 >> > >> > COMMITを切っても、sennaのインデックスは >> > 解放されないということですね。 >> > >> > 該当環境では、max_n_index_cacheを105に設定変更しています。 >> > というのも、1インデックスが2Gを超えるとエラーになるので、 >> > 分割するようにしたのですが、参照する際には、それらを >> > Viewを使って参照しているので、同時にsennaのインデックスを >> > オープンする数が増えるなあ、ということで。 >> > >> > お話からすると、今回のケースでは、12個目のインデックスで >> > エラーになっているので、それ以下に設定すれば、投入時の >> > エラーは回避できるかも知れませんが、 >> > 参照時にmax_n_index_cacheのために同時にオープンできなくて、 >> > または、max_n_index_cacheを増やしても、今度は、1プロセスの >> > メモリ取得でエラーになりそうな雰囲気ですね。 >> > >> > 現在、該当環境が無いので、参照系の確認ができず、 >> > 歯がゆいのですが、まず、max_n_index_cacheの設定変更で >> > どうなるかの確認は行いたいと思います。 >> > >> > >> >> 幸坂です。こんにちは。 >> >> >> >> 1プロセスのメモリ使用量が原因かもしれません。 >> >> max_n_index_cacheを小さい数字にすると、 >> >> 問題が解決する可能性があります。 >> >> >> >> max_n_index_cacheは1プロセスが開けるインデックス数です。 >> >> この値を超えてインデックスオープンを試みると、 >> >> LRU方式でインデックスをクローズし(sen_index_close)、 >> >> Sennaのメモリを解放します。 >> >> >> >> 以下の内容も参考にしてください。 >> >> >> http://lists.sourceforge.jp/mailman/archives/ludia-users/2007- >> October/000110 >> >> .html >> >> >> http://lists.sourceforge.jp/mailman/archives/ludia-users/2007- >> October/000123 >> >> .html >> >> >> >>> ちなみに、エラー後、以降の処理を再実行すると正常に格納されます。 >> >> エラーにより接続が切れて、全てのメモリが解放されたため、 >> >> 正常に動作していると思われます。 >> >> >> >>> -----Original Message----- >> >>> From: ludia-users-bounces @ lists.sourceforge.jp >> >>> [mailto:ludia-users-bounces @ lists.sourceforge.jp] On Behalf >> >>> Of sakamoto >> >>> Sent: Tuesday, December 18, 2007 2:02 PM >> >>> To: ludia-users @ lists.sourceforge.jp >> >>> Subject: [Ludia-users 157]データ投入時にメモリ確保エラー >> >>> >> >>> こんにちは、坂本です。 >> >>> >> >>> Windows上で、次のようなシーケンスで大量にデータ投入を行っています。 >> >>> (Ludia1.2+senna1.0.8) >> >>> >> >>> 1.全文検索インデックス1個を持った表1へデータを順次投入します。 >> >>> 2.インデックスサイズが約512MB近くになると、表1への >> >>>   データ投入を終了し、同一の構造を持った表2を作成し、 >> >>>   表2へデータ投入を続けます。 >> >>> 3.表2もインデックスサイズが約512MB近くになると、次に >> >>>   表3を作成し、表3へデータ投入を続けます。 >> >>> 4.このように1表の(1インデックスサイズ)をある程度抑えて、 >> >>>   順次表を追加していく形で大量データの投入を試みています。 >> >>> >> >>> ※1インデックスが2GBを超えると、メモリ確保できずにエラーと >> >>>  なる件がありましたが、それを回避するために表を分割しています。 >> >>>  また、1インデックスが1GBを超えると更新時の性能が出ない >> >>>  こともあり、切り替えの設定を低めにしています。 >> >>> >> >>> 本処理を実行し続けると、途中で、エラーで落ちます。 >> >>> 実際のSQLシーケンスとしては、 >> >>>   BEGIN → INSERT (100件程度)→ COMMIT >> >>> を繰り返しています。 >> >>> >> >>> Ludiaログの内容は、次の通りです。 >> >>> >> >>> 2007-10-24 04:40:42 LOG: pgsenna2: |A| malloc fail >> >>> (76836502)=00000000 >> >>> (..\lib\inv.c:922) <9617> >> >>> 2007-10-24 04:40:42 ERROR: pgsenna2: sen_index_upd failed >> >>> while do_insert >> >>> (1) >> >>> 2007-10-24 04:40:42 STATEMENT: INSERT INTO T_CSV_000012 >> >>> (SMGSEQ, PAGENO, >> >>> DATA) VALUES(502724, 1, ' >> >>> >> >>> Ludia1.3.1でメモリの解放に関する修正を行ったということで、 >> >>> これも確認しましたが、同じ場所で、同様に落ちます。 >> >>> >> >>> 2007-10-27 14:09:12 LOG: pgsenna2: |A| malloc fail >> >>> (76836502)=00000000 >> >>> (..\lib\inv.c:922) <9619> >> >>> 2007-10-27 14:09:12 ERROR: pgsenna2: sen_index_update failed 1,0 >> >>> 2007-10-27 14:09:12 STATEMENT: INSERT INTO T_CSV_000012 >> >>> (SMGSEQ, PAGENO, >> >>> DATA) VALUES(502724, 1, ' >> >>> >> >>> 少なくとも、COMMIT時にメモリも解放されて問題なく動作すると >> >>> 考えているのですが、1APから実行することによる弊害があるのでしょうか。 >> >>> >> >>> 合計は2GBを優に超えています。 >> >>> >> >>> ちなみに、エラー後、以降の処理を再実行すると正常に格納されます。 >> >>> >> >>> 何か考えらること、良い対応方法は無いでしょうか。 >> >>> >> >>> _______________________________________________ >> >>> Ludia-users mailing list >> >>> Ludia-users @ lists.sourceforge.jp >> >>> http://lists.sourceforge.jp/mailman/listinfo/ludia-users >> >>> >> >> >> >> _______________________________________________ >> >> Ludia-users mailing list >> >> Ludia-users @ lists.sourceforge.jp >> >> http://lists.sourceforge.jp/mailman/listinfo/ludia-users >> > >> > _______________________________________________ >> > Ludia-users mailing list >> > Ludia-users @ lists.sourceforge.jp >> > http://lists.sourceforge.jp/mailman/listinfo/ludia-users >> >> _______________________________________________ >> Ludia-users mailing list >> Ludia-users @ lists.sourceforge.jp >> http://lists.sourceforge.jp/mailman/listinfo/ludia-users >> > > _______________________________________________ > Ludia-users mailing list > Ludia-users @ lists.sourceforge.jp > http://lists.sourceforge.jp/mailman/listinfo/ludia-users From filipo2006 @ gmail.com Fri Dec 28 11:57:26 2007 From: filipo2006 @ gmail.com (ozawa) Date: Fri, 28 Dec 2007 11:57:26 +0900 Subject: [Ludia-users 166] =?iso-2022-jp?b?GyRCMWk7OztSJEckTyRKJC80WD90JEckTjhGJFM9UCQ3GyhC?= =?iso-2022-jp?b?GyRCMkRIXSRLJEQkJCRGGyhC?= Message-ID: 小沢と申します。 お世話になっております。 Ludiaで全文検索を実施する場合、@@演算子を利用することになると思うのですが、containsなどの関数で検索をかけることは可能でしょうか?(Oracle、DB2などでの場合、関数での呼び出し) 方法がございましたらご教授いただければと思いメールした次第です。 よろしくお願いします。 From kanout @ nttdata.co.jp Fri Dec 28 12:36:55 2007 From: kanout @ nttdata.co.jp (kanout @ nttdata.co.jp) Date: Fri, 28 Dec 2007 12:36:55 +0900 Subject: [Ludia-users 167] Re: =?iso-2022-jp?b?GyRCMWk7OztSJEckTyRKJC80WD90JEckTjhGJFMbKEI=?= =?iso-2022-jp?b?GyRCPVAkNzJESF0kSyREJCQkRhsoQg==?= References: Message-ID: 加納です。こんにちは。 Ludiaは、当初からPostgreSQL本体に手を入れないという 基本方針のもと開発しております。 お問い合わせの件は、PostgreSQLの本体に手を加える必要 がある内容となるため、現状、将来とも対応出来ない内容 となります。 # 初期検討時にJISのSQL編を取り寄せ、検討したのですけ # どね。現実問題として、PostgreSQLのバージョンアップ # への追随が出来ない(膨大な工数が必要となる)ことと、 # PostgreSQL本体の品質劣化が怖いのです。 > -----Original Message----- > From: ludia-users-bounces @ lists.sourceforge.jp [mailto:ludia-users-bounces @ lists.sourceforge.jp] On Behalf Of ozawa > Sent: Friday, December 28, 2007 11:57 AM > To: ludia-users @ lists.sourceforge.jp > Subject: [Ludia-users 166]演算子ではなく関数での呼び出し可否について > > 小沢と申します。 > お世話になっております。 > > Ludiaで全文検索を実施する場合、@@演算子を利用することになると思うのです が、containsなどの関数で検索をかけることは > 可能でしょうか?(Oracle、DB2などでの場合、関数での呼び出し) > > 方法がございましたらご教授いただければと思いメールした次第です。 > よろしくお願いします。 > > _______________________________________________ > Ludia-users mailing list > Ludia-users @ lists.sourceforge.jp > http://lists.sourceforge.jp/mailman/listinfo/ludia-users From filipo2006 @ gmail.com Fri Dec 28 13:53:03 2007 From: filipo2006 @ gmail.com (ozawa) Date: Fri, 28 Dec 2007 13:53:03 +0900 Subject: [Ludia-users 168] Re: =?iso-2022-jp?b?GyRCMWk7OztSJEckTyRKJC80WD90JEckTjhGJFMbKEI=?= =?iso-2022-jp?b?GyRCPVAkNzJESF0kSyREJCQkRhsoQg==?= In-Reply-To: References: Message-ID: 本件了解しました。 根本的に難しいということですのであきらめがつきます。 ご回答ありがとうございました。 07/12/28 に kanout @ nttdata.co.jp さんは書きました: > 加納です。こんにちは。 > > Ludiaは、当初からPostgreSQL本体に手を入れないという > 基本方針のもと開発しております。 > > お問い合わせの件は、PostgreSQLの本体に手を加える必要 > がある内容となるため、現状、将来とも対応出来ない内容 > となります。 > > # 初期検討時にJISのSQL編を取り寄せ、検討したのですけ > # どね。現実問題として、PostgreSQLのバージョンアップ > # への追随が出来ない(膨大な工数が必要となる)ことと、 > # PostgreSQL本体の品質劣化が怖いのです。 > > > > -----Original Message----- > > From: ludia-users-bounces @ lists.sourceforge.jp > [mailto:ludia-users-bounces @ lists.sourceforge.jp] On Behalf Of ozawa > > Sent: Friday, December 28, 2007 11:57 AM > > To: ludia-users @ lists.sourceforge.jp > > Subject: [Ludia-users 166]演算子ではなく関数での呼び出し可否について > > > > 小沢と申します。 > > お世話になっております。 > > > > Ludiaで全文検索を実施する場合、@@演算子を利用することになると思うのです > が、containsなどの関数で検索をかけることは > > 可能でしょうか?(Oracle、DB2などでの場合、関数での呼び出し) > > > > 方法がございましたらご教授いただければと思いメールした次第です。 > > よろしくお願いします。 > > > > _______________________________________________ > > Ludia-users mailing list > > Ludia-users @ lists.sourceforge.jp > > http://lists.sourceforge.jp/mailman/listinfo/ludia-users > > _______________________________________________ > Ludia-users mailing list > Ludia-users @ lists.sourceforge.jp > http://lists.sourceforge.jp/mailman/listinfo/ludia-users >