[pgsql-jp: 41699] Re: nestloop時の動作について
prod2011 @ yahoo.co.jp
prod2011 @ yahoo.co.jp
2014年 7月 23日 (水) 15:24:20 JST
prodです。
花田様、早速のご返信ありがとうございます。
Windows版であれば、用意できたため、Windows版でためしました。
OS:Windows7
Postgres:PostgreSQL 9.3.4, compiled by Visual C++ build 1600, 32-bit
しかし、残念ながら、結果は変わらずで、
nestloopだと、おかしい結果のままでした。
----- Original Message -----
> From: Shigeru HANADA <hanada @ metrosystems.co.jp>
> To: prod2011 @ yahoo.co.jp; PostgreSQL Japanese Mailing List <pgsql-jp @ ml.postgresql.jp>
> Cc:
> Date: 2014/7/23, Wed 13:11
> Subject: Re: [pgsql-jp: 41696] nestloop時の動作について
>
> 花田です。
>
> 9.1.11で修正されたバグではないでしょうか。
>
> 【9.1.11 リリースノートより】
> ------------------------------------------------------------------------
> ・副問い合わせのSELECT内部にラップされた揮発性関数をもつSELECTの副問い合
> わせの平坦化を避けるようにしました。(Tom Lane)
>
> これにより、揮発性関数の余計な計算による予期しない結果を避けることができ
> ます。
> ------------------------------------------------------------------------
>
> ここでいう「揮発性関数」はVOLATILE関数のことで、nextval()はVOLATILE関数
> の一つです。
> 参考:http://www.postgresql.jp/document/9.1/html/xfunc-volatility.html
>
> 9.1.11またはそれ以降のバージョンで試せませんか?
>
> (2014/07/23 11:14), prod2011 @ yahoo.co.jp wrote:
>> こんにちは。Prodと申します。
>>
>> 今回あるSQLで、オプティマイザの実行計画により、結果が異なる。
>> という事象に遭遇しました。
>> 実行計画で、結果がことなるのは、
>> Postgresの不具合なのでは?と思い、皆様に見ていただきたいとおもい
>> メールさせていただきました。
>>
>> OS:RedhatES 5.3
>> Postgres:PostgreSQL 9.1.2
>>
>> 実際のSQL-------------------------------------------
>> select
>> dt.syoid,dt.anycd,dt.NO015,dt.dataid
>> from
>> wrk_tri wtri
>> inner join
>> (
>> SELECT
>> wrk.syoid
>> ,nextval('seq_dataid') as dataid
>> ,CONCAT(1407 ) AS denno
>> ,wrk.anycd AS anycd
>> ,wrk.no015 AS no015
>> FROM
>> wrk_tri wrk
>> WHERE wrk.syoid = 201400009301
>> AND wrk.anycd = '67458'
>> AND wrk.ykofg <= 1
>> GROUP BY wrk.syoid,wrk.anycd,wrk.no015
>> ) dt
>> on (wtri.syoid = dt.syoid AND wtri.anycd = dt.anycd AND wtri.no015 =
> dt.no015)
>> where wtri.anycd = '67458'and wtri.syoid = 201400009301
>> order by dt.dataid
>> --------------------------------------------------------
>>
>> dataidをsyoid,anycd,no015単位で、シーケンスにより採番するために作成しました。
>> 副問合せの中身も、外側でJoinしているテーブルも同じテーブルです。
>> ※ 本来は、Updateしているのですが、selectでも同じ事象になったので、
>> selectの方で質問しております。
>>
>> こちらを実行すると、
>> syoid anycd no015 dataid
>> 201400009301674582169939
>> 201400009301674582169943
>> 201400009301674582169947
>> 201400009301674582169951
>> 201400009301674581169956
>> 201400009301674581169960
>> 201400009301674581169964
>> 201400009301674581169968
>>
>> と副問合せ部分で取得したdataidのシーケンスばバラバラとなります。
>> 副問合せの部分で、syoid,anycd,no015でGroup byしておりますので、
>> 期待した動作は、syoid,anycd,no015単位に同じdataidが取得するということです。
>>
>> 上記SQLの実行計画は、nestloopでしたので、
>> ここで、
>> set enable_nestloop = off;
>>
>> として、もう一度試すと、
>>
>> syoid anycd no015 dataid
>> 201400009301674582169935
>> 201400009301674582169935
>> 201400009301674582169935
>> 201400009301674582169935
>> 201400009301674581169936
>> 201400009301674581169936
>> 201400009301674581169936
>> 201400009301674581169936
>>
>>
>> とsyoid,anycd,no015単位に同じdataidが取得できました。
>>
>> SQL自体全く変更していないのに、実行計画で、
>> 結果が異なるのはpostgresの不具合では?
>> と感じるのですが、そもそもこんなSQLは使ってはいけない。
>> などありましたら、ご教授いただければ幸いです。
>>
>> よろしくお願いします。
>>
>
> --
> 株式会社メトロシステムズ
> インテグレーション事業部
> 花田茂
> TEL: 03-5951-1219(部門直通)
>
pgsql-jp メーリングリストの案内