p.tatapa.org

p.tatapa.org

ると | @ruto@p.tatapa.org

プログラミング(関数型言語とJava多め)、その他言葉遊びなどを書いてます。アイコンは「腕時計」。ヘッダー画像は2-3フィンガーツリー。

PostgreSQLを17に上げたらpg_stat_bgwriterビューから列が大幅に削除されてて、そのせいでOpenTelemetry CollectorのPostgreSQL Receiverがエラーを吐き続けている。処理自体は継続してるので良いんだけど。

https://www.postgresql.org/docs/current/release-17.html#RELEASE-17-MONITORING
https://github.com/open-telemetry/opentelemetry-collector-contrib/pull/36813

PostgreSQLって堅実なイメージだけと割と大胆に非互換の変更入れるんだね。いや、リリースノートにいつも非互換性のリストがけっこうな長さであるのは見てたけど。

クローズなマイクロブログを今更追加する気が起きない……。

“lionize”(英雄視する/有名人扱いする)という単語を見てt_wadaさんを連想した。

NAIRI: Rising Tideクリアした。
https://store.steampowered.com/app/1225200/NAIRI_Rising_Tide/
かわいい絵の割にパズルが難しくて、スライドパズルの一番難しいやつはソルバ書いて解いた(ゲーム内にヒント機能もあるのでそれでも見れたかも)。答え見てもその動きは思いつかないよみたいな感じだった。このマスはこの動きでしか消せないみたいなのをもっと詰めてけば解けたのかもしれない。

だからこう言ったんだ。

「このアドベントカレンダーには素敵なものが入った引き出しがあるな。素敵なものが入った引き出しは毎日深夜0時と同時に出てきておくれ」

今のところ誰も出てこない。でも25日に日付が変わった瞬間、全員出てくるはずさ。

#いろいろなアドベントカレンダー

あのアドベントカレンダーの引き出し達は自分の中に何が入ってるかわからないんだ。でも他の引き出しの中身は全部見えるから不安で仕方ないんだ。みんな素敵なものが入っているのに、自分だけ変なものが入ってるんじゃないかってね。

銃刀法における「あいくち」って普通のナイフとどう違うのかと思って調べてみたら、「社会通念上あいくちの類型に当てはまる形態・実質を備える刃物」ということらしい。

https://www.courts.go.jp/app/hanrei_jp/detail5?id=16442

しかも単体ではなく鞘と一体としたものとして当てはまるか判断するらしい。

今度から「○○の定義は何か」って聞かれたら「社会通念上○○の類型に当てはまるもの」って答えよう。

#いろいろなアドベントカレンダー

昨日まで空き地だったところに大きなビルが建っていた。

「最近はAIのおかげで1日でビルが建つようになったんですよ」

言われてみれば、遠くの方の景色が随分変わっていた。

科学者「生物多様性は急激に減少しており、自然とのふれあいの減少による健康への悪影響が懸念されている」

わたし「ふむ」

科学者「本研究では鳥の鳴き声によるサウンドスケープの多様性と音量に注目した」

わたし「なるほど」

科学者「実験としてぶどう園ツアーにおいて隠しスピーカーでその園にいない鳥の鳴き声を再生したところ、参加者の音の楽しみ度合い・サウンドスケープとの繋がり・ツアーの満足度が向上した」

わたし「えー、ありなのそれ?」

https://besjournals.onlinelibrary.wiley.com/doi/full/10.1002/pan3.10721

参加者には終了後にスピーカーの使用が開示されたらしい。

そのうち脳波でLLMと会話できるようになって、会話記録が警察に押収されるようになる。

ラニーニャ現象には正式にはまだなっていなくて、なったとしても弱いものになる見込みらしい。ただし、今年は海水温が全体的に高めで、そのせいでラニーニャ現象が数字上弱く見えているらしい。熱帯の平均海水温からの相対値で見るとすでに7月からラニーニャ現象となっていたとも言えて、大気の状態を見てもラニーニャ現象の特徴を示しているらしい。
https://www.climate.gov/news-features/blogs/enso/december-2024-enso-update-party-time-excellent

#いろいろなアドベントカレンダー

「俺は毎年アドベントカレンダーを開け続けてここまで登り詰めてきた。ただ、そんなに都合よく毎年アドベントカレンダーを開け続けられるだろうか。誰かが負けたフリをして、裏から糸を引いているとしたら」

スターバックスコーヒーではスターバックスコーヒーという名前の商品は売っていない。
モスバーガーではモスバーガーという名前の商品を売っている。
ここから対角線論法かラッセルのパラドックスに持ってけないだろうか。

トルコにトルコライスは無くてアンデスにアンデスメロンが無いんだから、きっとケンタッキー州にもケンタッキー・フライド・チキンは無くて、埼玉かどこかが発祥に違いない。

アメリカン・エにゅにゅにゅにゅにゅ

・ケンタッキー州にもマクドナルドはある。

・スターバックスコーヒーで売っているコーヒーはスターバックスコーヒーという名前ではない。

・「セロハンテープ」や「セロファンテープ」とは言えるのに「チェロハンテープ」や「チェロファンテープ」は言えない。

・「アメリカン・エクスプレス」ではなく「アメリカン・エキスプレス」なのに「アメッキス」ではなく「アメックス」である。

こういった感情を他人と共有するのは難しい。おそらく半年後の自分とも共有できないかもしれない。

https://soudai.hatenablog.com/entry/2024/12/10/115848

履歴テーブルから各ユーザの最新のデータを1件ずつ取ってきたい場合、PostgreSQLの場合は次のように書いた方が高速な場合がある。

SELECT
  latest.*
FROM
  users,
  LATERAL (
    SELECT
      *
    FROM
      history
    WHERE
      history.user_id = users.user_id
    ORDER BY
      created_at DESC
    LIMIT
      1
  ) AS latest;

ウィンドウ関数を使う場合やDISTINCT ONを使う場合、インデックスがあっても線形スキャンとなる。

一方、前記のクエリの場合(あるいは入れ子ループでインデックスを引くような同等のクエリの場合)、インデックスを使って最新の行のみにアクセスするため、最新以外の行が多い場合は高速になる。

さらに複雑な条件が必要な場合は再帰CTEを使った方法が使える: https://wiki.postgresql.org/wiki/Loose_indexscan

多くの場合は最新データを別テーブルにする方法でよいんだけど、任意の時点における最新データを取得したい場合や、何らかの理由で別テーブルを作りたくない場合はこの手法が使える。

インデックスは(user_id DESC, created_at DESC)で作っておくとよい。

いずれにしろ実行計画を見て、さらに実データに近いデータでベンチマークを取ってちゃんと速くなっているか確認する必要がある。

無記名Suicaは匿名で使える貴重な電子マネーなので、維持・販売し続けてくれると嬉しいんだけど、JRとしてはあまりそのインセンティブが無さそう。

https://www.jreast.co.jp/press/2024/20241210_ho03.pdf

#いろいろなアドベントカレンダー
朝起きると新しい楽譜がピアノに置かれている。右側の椅子に座ると左から音が鳴り始め、私も弾き始める。難しかった部分も今は滑らかに弾ける。

»