0009NAME IS NULL2016/05/17(火) 12:51:27.21ID:??? DBバージョン上げたら insert into a select * from a_tmp where code = 1 で 列"b_flg"は型booleanですが、式は型textでした ってエラー出るようになったんだけど、 CREATE CASTで対処するのが正しい道? 0010NAME IS NULL2016/05/17(火) 13:09:37.70ID:???>>9 エスパー求む 0011NAME IS NULL2016/05/17(火) 13:23:11.87ID:???>>9 そこで動かなくなるのってかなり古かったんじゃないか?
a_tmp にある b_flg に相当する列の型を boolean に変更すべきだろう。 CREATE (TEMP?) TABLE a_tmp (LIKE a) すればミスを避けられる。 0012NAME IS NULL2016/05/17(火) 13:28:59.38ID:??? エスパーじゃないとわかんないのかw
説明すると table a code integer b_flg boolean
table a_tmpも同じ構成のテーブル
で、booleanのフィールドがTRUEとか返すんだけど、それが 文字列だと思われてエラーになるみたい # 8.4くらいから? 0013NAME IS NULL2016/05/17(火) 14:40:07.89ID:???>>11 もちろんa_tmpの b_flgの型はbooleanです。 0014NAME IS NULL2016/05/17(火) 15:00:34.52ID:??? って自分でテーブル作って同じの試したらうまくいく・・・・
select b_flg from a_tmp で TRUEが帰ってくる時と tが帰ってくる(こっちでエラーになる)のあるんだけど、何違うんだろ・・・ 0015NAME IS NULL2016/05/17(火) 15:07:39.56ID:??? 「boolean型」なのか「text型にbooleanっぽい文字列が入ってる」のかをきちんと確認したほうが良い。 特にSELECT INTOでテーブルを作るような場合だと型指定が曖昧な場合がある。 0016NAME IS NULL2016/05/17(火) 15:33:03.01ID:???>>9 > DBバージョン上げたら 何から何に上げたのか
> insert into a select * from a_tmp where code = 1 どこでこれを実行しているのか
> table a_tmpも同じ構成のテーブル 本当か?
> で、booleanのフィールドがTRUEとか返すんだけど 何で実行するとそうなるのか
> 文字列だと思われて 思う主体は何か? 0017NAME IS NULL2016/05/17(火) 15:35:23.64ID:??? > って自分でテーブル作って同じの試したらうまくいく うまくいく環境と、うまくいかない環境の差異は何か 0018NAME IS NULL2016/05/17(火) 15:42:34.62ID:???>>9 > CREATE CASTで対処するのが正しい道? なわきゃない 0019NAME IS NULL2016/05/17(火) 20:41:11.06ID:??? なぜテーブル定義を確認しないんだろう... 0020NAME IS NULL2016/05/18(水) 13:16:35.30ID:??? 確認した結果同じ構成だったんだろ 知らんけど 0021NAME IS NULL2016/05/21(土) 16:12:15.04ID:??? 質問: shared_bufferを16GBに設定しているのに、実際にはそれ以下しか使用されてないっぽいんだが、どういうことでしょうか。
sahred_bufferの値が16GBであることを確認
$ grep shared_buffers /etc/postgresql/9.3/main/postgresql.conf shared_buffers = 16GB # min 128kB
WHERE句で解決を試みようとも思いましたが、ユニークな値でORDER BYをかけているわけではないため、不可能と判断しました。 ORDER BYで対象としているカラムの結果は同じ値のものも含まれており、 その同じ値の続く途中で件数によって区切られた場合、そのカラムをWHEREの対象にはできません。
助けてください。 0062NAME IS NULL2016/08/13(土) 22:33:42.60ID:??? ソートキーは当然あるわけだから、「前回の最後のソートキーより大きな100件」を取得すればいいんでない? 0063NAME IS NULL2016/08/14(日) 03:22:54.54ID:???>>62 すいません、ソートキーというのはORDER BYで指定するカラムですよね。 そのカラムの値がユニークではないので、その値で判定できないんです。 このようなイメージです。
〜 ORDER BY score;
score -------- 2500 2800 3000 3000 3000 3400
例えばこれで3件ずつ取得するためにLIMIT 3を付けた場合、3000のスコアの途中まで取得されるので、 WHERE > 3000というような形で指定できないのです。 0064NAME IS NULL2016/08/14(日) 06:01:16.47ID:??? テンポラリテーブル作って検索結果突っ込んでおくとか 主キーだけでも 0065NAME IS NULL2016/08/14(日) 07:47:45.50ID:???>>61 続きを取得している間はトランザクションは開きっぱなしなのか? 更新されても結果が変化しないのが条件なら 開きっぱなし or 全行を一時保管しておく必須がある
トランザクションを切るなら並行する更新結果も見えてしまうが 更新によって主キーとソートキーが変わらないならば 「欲しいソートキー + 主キー」を条件にすればいい ORDER BY score, pkey WHERE score >= 前回のscore AND pkey > 前回のpkey 0066NAME IS NULL2016/08/14(日) 09:02:39.41ID:??? 実はユニークな主キーもないとか言い出したりして。 0067NAME IS NULL2016/08/15(月) 07:13:36.14ID:??? うぎゃ 0068NAME IS NULL2016/09/04(日) 22:19:47.07ID:??? 次のバージョンって10になるのん? 0069NAME IS NULL2016/09/06(火) 00:48:17.74ID:???>>68 9.6 0070NAME IS NULL2016/09/11(日) 05:22:55.47ID:??? どうしてPostgreSQLはMySQLに勝てたのか 0071NAME IS NULL2016/09/16(金) 04:50:18.57ID:???>>63 score が 3000 であるレコード同士の順番をどうにかして決めておかないとだめだよ。