カーソルを使ったら、問い合わせの回数が減って、速くなった。

・エ・）というヒントをもらったので、いっぺんにやろうとしないで、別個に実行するようにプログラムを作ることにした。
・エ）ためしに、やってみると、1回目は遅いけど、その後は、はやくなる。
・エ）1分ちょっとかかってたやつが10秒ぐらいで上がる。
・エ・）問い合わせ計画ってやつをいっぺん作ったら、それを再利用するから速いのか、
それとも、メモリーにある程度はいるから速いのか。

他の処理も、6年分一度にやろうと思うと2、3日かかってしまう。
とても、普段持ち歩いているノートパソコンではやってられない。
ので、LINUXパソコンか、ウィンドウズ版のpostgresqlをつかって、やらせてみようかと思う。
＝エ）ウィンドウズだと、1日一回は再起動必要かな？？？
すると、ウィンドウズは使えないってことになるな。

order by を使う時、反射的にgroup byをつかってしまうことが多いので、整理してみると、結構速くなったりした。

改めて計ってみると5分だった
1週間を作るのに5分、1年を50週とすると、250分、6年で
1500分、時間にすると25時間♪
次の休みの日にすることにしよう。。。

週足をつくるために、1週間ノデータの抽出にdate_part()関数をつかったのだが、どうも遅い。たった、1週間のことを出すだけなのに、10分ぐらいは軽くかかる。
これでは6年分をいっぺんにやろうとすると、＝エ）50時間もかかってまう。
データの量が多いからかもしれない。
それに対して、月足は速い。
＝エ）ひと月は、1日から始まるから、betweenを使って、簡単に抽出範囲を指定できるからだ。
＝エ）でも、週足はちがう。祭日で、月曜日が休みのこともあるし。
月曜日では指定できないからだ。
それで、date_part()関数を使ってweekで指定して、取り出すほかない。
他にいい方法あるだろうか。。。
ちなみに、
between date ’19980105’ and date ’19980105’+ interval ’1 week’
こうやってみると、次の週の1日分が入ってしまう。
+ interval ’1 day’をくわえれば、調整できそうだが、
＝エ）挙動を完全に把握できない意味で反則だ。
+ interval ’5 day’もやはり、反則。

＝エ）週足、月足、σバンド、移動平均、HLバンド、パラボリックタイムプライス、pivot、一目均衡表だけだけど、作れるようになった。
＝エ）ただ、また、週足、月足をつかったσバンドと移動平均線、はできていないので、つくラニャならん。
パラボリックタイムプライスは、週足、月足では用をたさないと思う。
オシレーター系はイランと本に書いてあったので、（俺自身も使いにくいと判断した）最低限のトレンドフォロー型を用意した。
暇があったら、用意していく。

きのう、SQLでユーザー定義関数を作ってみた。
そのあと、ループを使いたかったから、ついでにPL／pgSQLも使って書いてみた。
トリガー用に引き数を必要としないように作る。
存外簡単。

どのみち、ユーザー関数を作らないと行けない。

＝エ）ユーザー定義関数を作れば、SQLを短くできるし、別個で実行せざる終えないSQLをくっつけれるかもしれない。
＝エ＝）ただ、時間が経つと、自分がどんなユーザー定義関数を設置したのか忘れてしまうのが心配でならない。。。

重複しない日付の列を月ごとに分けて、トップとラストを抽出したいのだが。
＝エ）最近なんだか、マシン語扱ってる気分。
んー、まず、日付の列の日にちのところを統一してしまって、
同じ結果が出せるSQL
select distinct to_date(to_char(cast(date as timestamp)， ’yyyy-mm-01’)， ’yyyy-mm-dd’) from stockprices ;

下記のSQLが速い。
select distinct to_date(to_char(cast(date as timestamp)， ’yyyy-mm-01’)， ’yyyy-mm-dd’) from stockprices group by date ;
検索しなきゃならない年月を列挙する。

・エ）1ヶ月分のち、を指定するときにつかってみた。
・エ・）前日指定は　-1 month
・エ）timestampで返されるので、
cast(date ’20050201’ + interval ’1 month’ as date)
こう書いてdate型にcastしてやらないと、いつまでたっても返事が返ってこない。

・エ・）過去三日ぐらい上がってたからって、買ったところで、下がる。短期的に見たら、負けだ。
だからといって、下がっているやつを買ったところで、さらに下がる。どこまで下がるかも見当がつかん。
・エ）やっぱり、先の高値を超えたところで買いを入れて、
先の安値を下回ったときに売りにするしかないのかもしれない。
＝エ）銘柄選択の助けにするというよりは、待ち受けるポイントを市場が始まる前に設定しておく、それだけの助けにしかならないのかもしれない。
とはいえ、限られた資金で、限られた銘柄しか購入できないのなら、やっぱり、えらばなあかんわけで。。。
・エ）とりあえず、トレンドを読んで、3通りに分けるしかないかなぁ
上昇中、トレンドなし、下落中の3つ。
上昇中や、下落中は、いつ落ちだしたり、上がりだしたりするか、わからないので、短期。
トレンドなしは、そのうち上がるやろうから、中期から短期。
信用をするのなら、現金は、トレンドなしな銘柄を購入するのに使って、
それを担保に短期用の資金を用立てた方が、チャンスが広がりそう。
・エ）よそ事している間に、日経平均11900円台になっちゃいました。。

・エ・）あんこに教えてもらった

SQLでifみたいなものはないんだろうか。。。
もし、こっちだったら、こっちのしょり、
だめだったら、こっちのしょり、って、
・エ・）できたら、簡単に作れるんだが。。

設計がどうしたらいいのかわからないで、自分なりに考えてやっていたが、
人にこうやるといいと、方向転換を指示されて、言うことを聞きたくないけど、一理有りと思い言うことを聞いて、やってみると、あっさり問題解決したりして、ちょっと気がそがれた気分だったけど、気を取り直して、本来の目的の処理をDBにやらせてみる。
selectして、でた結果は、テーブルとして仮定して、さらに、それに他のテーブルをくっつけて、selectしたりして、
・エ・）SQLで一発で出すように工夫してみる。
長くて読みにくいけど、存外簡単に結果がでる。
でも、白と黒が分かれただけのような。。。。

select distinct date from stockprices order by date desc;
と
select date from stockprices group by date order by date desc;
これ
select date from stockprices group by date order by date desc;
の方が速い

って言うのがあるけど、ぼくがほしいようなチャートは作れないようだ。
ろうそくって、openclosehighlowがわかればええってことではなくて、あの、白黒にも、意味があるのよね。

・エ・）集合関数がうまく使えないと、詳しい人（HNを出していいのかわからんから、これでええやろ）に聞いたら、joinを使えば一発や、って言うので、使ってみたら、うまくいった。
＝エ＝）こういうときにつかうんやなぁ、結合って。

GroupAggregate (cost=2499166.88..2553796.50 rows=40001 width=34) (actual time=131256.980..131463.148 rows=4788 loops=1)
-> Sort (cost=2499166.88..2510072.80 rows=4362370 width=34) (actual time=131256.874..131298.983 rows=23920 loops=1)
Sort Key: a.brandcode， a.marketcode， a.date
-> Merge Join (cost=1468150.09..1544804.86 rows=4362370 width=34) (actual time=130542.438..130772.830 rows=23920 loops=1)
Merge Cond: (("outer".marketcode = "inner".marketcode) AND ("outer".brandcode = "inner".brandcode))
-> Sort (cost=169198.08..169302.51 rows=41773 width=30) (actual time=363.333..366.063 rows=4788 loops=1)
Sort Key: a.marketcode， a.brandcode
-> Index Scan using stockprices_pk on stockprices a (cost=0.00..165396.55 rows=41773 width=30) (actual time=58.714..265.123 rows=4788 loops=1)
Index Cond: (date = ’2005-02-25’::date)
-> Sort (cost=1298952.01..1309395.05 rows=4177214 width=30) (actual time=130179.032..130229.218 rows=23927 loops=1)
Sort Key: b.marketcode， b.brandcode
-> Seq Scan on stockprices b (cost=182516.99..417241.50 rows=4177214 width=30) (actual time=129053.730..129325.792 rows=23927 loops=1)
Filter: (subplan)
SubPlan
-> Materialize (cost=182516.99..182517.00 rows=1 width=4) (actual time=0.008..0.008 rows=1 loops=8354427)
-> Limit (cost=182516.99..182516.99 rows=1 width=4) (actual time=63139.995..63139.997 rows=1 loops=1)
-> Sort (cost=182516.98..182517.48 rows=200 width=4) (actual time=63139.978..63139.981 rows=5 loops=1)
Sort Key: date
-> HashAggregate (cost=182509.34..182509.34 rows=200 width=4) (actual time=63120.574..63126.495 rows=1760 loops=1)
-> Seq Scan on stockprices (cost=0.00..161623.27 rows=8354427 width=4) (actual time=0.028..44834.175 rows=8354427 loops=1)
Total runtime: 131604.548 ms
(21 rows)