年末アップしようと思って忘れてたので。 postgresqlのtranslate関数は、複数の文字を変換することができるので、 1文字対1文字の変換であれば、文字に限らず数字アルファベットも1文ですべて変換してしまうことができます。 問題は濁点、半濁点まじりの文字の場合。 これは1文字対1文字の置き換えではないので、replace関数を順番に適用していくしかないです。 この際注意しないといけないのが、WHERE句の指定で、これが無いとすべての行に対してUPDATEが走ってしまうので、 件数が2桁万件くらいになるとpostgresqlの場合パフォーマンスで問題が出ます。 というわけでコピペ用コードは以下。[table_name]、[column_name]を適切なテーブル名とカラム名に置き換えてくださいな。 UPDATE [table_name] SET [column_name] = re
STEP.2 関数を作成してSQL文を簡略にする このままではSQL文を書くのが面倒なので、関数を作成してSQL文を簡略にします。 CREATE OR REPLACE FUNCTION get_nocase_text (text) RETURNS text AS $$ SELECT translate(upper($1) ,'-0123456789ABCDEFGHIJKLMNOPQRSTUVWXYZ ' ,'-0123456789ABCDEFGHIJKLMNOPQRSTUVWXYZ '); $$ LANGUAGE SQL IMMUTABLE; と関数を作成しておくと、SQL文は次のようになります。 SELECT 商品cd, 商品名 FROM t_商品台帳 WHERE get_nocase_text(商品名) LIKE 'A4%'; STEP.3 式インデックスで高速にする 特定の列について
中規模サーバーのapache+postgreSQLのチューニング ■ apache+php+DBの難しさ apacheのチューニングのページはいろいろありますが、どれも大体同じ内容が書かれています。また、それほどチューニングする要素も無いようで、それだけapacheの完成度の高さを示しているとも言えます。 例えばこちらでは、maxclients/minspareservers/maxspareservers/startserversに関する設定例を示しています。 これに対し本家jでも、チューニングをサーバーの用途によってケース分けをして紹介していますが、maxclientsの設定のみに触れており、お世辞にもチューニングと言えるものではありません。 チューニングというよりは、「maxclientsの設定」でしょうか。 apache+php+DBの場合は、phpによるWebサーバーの負荷が(
PostgreSQLのチューニング PostgreSQLは最適なパフォーマンスが出るように自動的に調整されるため、特別なチューニングテクニックは必須ではありませんが、最大限にパフォーマンスを引き出したい場合にはpostgresql.confで指定している値を調整することによりチューニングが可能です。また、PostgreSQLのパフォーマンス向上のためには定期的にVACUUMコマンドを実行することをお奨めします。 ■VACUUMコマンドを実行する VACUUMコマンドはPostgreSQLデータベースの掃除と解析をおこなうコマンドです。 定期的にVACUUMコマンドを実行するとデータベースの問い合わせのパフォーマンスが向上します。 VACUUMコマンドによる処理はテーブルが大きい場合は時間がかかりますので、あまりアクセスのない時間帯におこなうとよいでしょう。 ●VACUUMコマンドの文法 v
へんじがない。ただのポンコツのようだ。 ポンコツが今日も持ち場でガンバリつつ、 楽しく生きていくための備忘録ブログ。ぬわーーっっ!!2005年7月から絶賛「更新」中! またまた、Postgresqlのパラメータチューニングネタというか、同時接続数ネタですが、LAPPの場合、Apacheの同時接続数とPostgresqlの同時接続数という話になると思う。 よくありがちなのが、パラメータをデフォルトで使っていておかしくなってしまうパターン。 よくあるのが、Apacheの同時接続数が150で、postgresqlの同時接続数が32というもの。 PostgresSQLの同時接続数 Apache+PHP+PostgresSQLでサーバーを運用しています。アクセス数が多くなるとApacheが停止してしまいす。そのためボトルネックの調査をしているのですが、Apacheの同時リクエスト数(MaxClien
PostgreSQL 7.4.3 on i586-momonga-linux-gnu, compiled by GCC gcc (GCC) 3.2.3 (Momonga Linux 1.0 3.2.3-12m) にて確認しました。 普通に以下のSQLを実行すると、 ALTER TABLE c_member_pre ADD COLUMN login_id varchar(255) NOT NULL default ''; こんなエラーが出るわけです。 ERROR: adding columns with defaults is not implemented default を外してもエラーが。 ALTER TABLE c_member_pre ADD COLUMN login_id varchar(255) NOT NULL; ERROR: adding NOT NULL columns
WordPress2.9.2をPostgreSQLで動かしてみた WordPressで使用するデータベースは基本的にはMySQLだが、 MySQLサーバを作るのが面倒だったので、すでに使用しているPostgreSQLサーバで動かしてみた。 構成 WordPress 2.9.2 日本語版(最新の3.1.2ではPG4WP 1.1.0が動作しなかった) PG4WP 1.1.0 (WordPressをPostgreSQLで動作させるプラグイン) PHP 5.2.3 PostgreSQL 8.0.6 PostgreSQLのデータベースユーザとデータベースを作成 #createuser --createdb --no-adduser --pwprompt wpadmin #createdb -U wpadmin -E UTF-8 wp_hogehoge WordPressのwp-config.phpを
最新文章 2018-12-26 07:29▪ 一男子高速“飙车”后拍视频晒微信群因涉嫌危险驾驶罪被拘... 2018-12-26 07:29▪ 嘉定优化营商环境为企业办事提速增效 2018-12-26 07:29▪ “论证西游记是自己所写”,有些奇葩考题不值得提倡 2018-12-26 07:29▪ ?元旦春节将至干部职工可享有正常福利待遇每人每年可领... 2018-12-26 07:29▪ 网络女主播与“阔绰”粉丝成恋人被骗25万元 2018-12-26 07:29▪ 福建龙岩一公交车被歹徒劫持冲撞行人已致5死21伤 2018-12-26 07:29▪ 雷寒、李洪被撤销重庆市政协委员资格 2018-12-26 07:29▪ 西双版纳公开销毁逾2000件非法枪支、猎具、毁林器具 2018-12-26 07:29▪ “市民云”成全国首个用户逾千万政务APP,有235项服务 2018-12-
諸々の事情によりEUC-JPのDBをダンプ→UTF8のDBにリストアするというスクリプトを毎日バッチで実行しているが、ある日突然エラーを吐いてデータのインポートができなくなった。 pg_restore: [archiver (db)] COPY failed: ERROR: character 0xfce2 of encoding "EUC_JP" has no equivalent in "UTF8" ということなので、EUC-JP の 0xfce2を確認してみると、「(はしごたか)」だった。この周りの文字はいろんなところでトラブルが起こる。「(たつさき)」も同様。 そこで、ほかのエンコードについても対応する文字の区点を調べてみる。 http://pentan.info/doc/sjis_list.html SJIS UTF8 UTF16 EUC-JP JIS 文字
NTT オープンソースソフトウェアセンタ 鈴木 幸市 3. 論理バックアップとリストア 論理バックアップを行うツールは pg_dump 及び pg_dumpall です。 pg_dump は PostgreSQL データベースクラスタの各データベース単位にバックアップを行います。pg_dumpall はターゲットのデータベースクラスタに格納してある全データベースのバックアップを行います。 pg_dump も pg_dumpall も、バックアップデータはデータベースを復元するために必要な SQL 文で構成されます。 従って、pg_dump や pg_dumpall を使うと PostgreSQL データベースの内容を別なデータベースに移行したり、特定のテーブルだけをバックアップしたりすることが可能となります。 pg_dump, pg_dumpall を使うためには特別な用意はいりませんが、
まず、ソースを入手します。 https://www.postgresql.jp/ PostgreSQLには主に7.4系、8.0系、8.1系、8.2系などがあります。今から新規に使うのであれば、できるだけバージョンの新しいのを使う方が良いです。バージョンが新しい方がアクセス速度やメモリ効率など、色々な点で改良されているからです。 ただ、現在すでに動いているシステムからのアップデートであれば、同じメジャー番号の最もマイナーバージョンの高いものを使う方が無難です。マイナーバージョンは主にセキュリティパッチやバグ修正のたびに更新されますので、マイナーバージョンが大きいという事は、それだけ安定した動作が期待できるからです。 バージョン7.2から7.3になる時に、int型に''(空文字列)をinsertするとエラーになるというルールができました。これは他のSQLの規則と合致していて良いルールなのですが
今までsyslogに吐いていましたが、ローテーションがsyslog任せになってしまうので標準出力させてみました。postgresql.confを修正。環境はPostgreSQL8.1.11。 ●とりあえず標準ログ出力。 log_destination = 'stderr' ●標準出力用の設定。標準出力のリダイレクトをONにする。 redirect_stderr = on ●リダイレクトしたログのファイル出力先ディレクトリを設定する。 このディレクトリはDBユーザーの権限で作成すること。 log_directory = '/var/log/postgresql' ●1週間でローテーションする時はログファイル名を***.曜日で作成する。 log_filename = 'postgresql.log.%a' ●同名のファイルが存在する時は上書きする。ローテーション用。 log_truncate_
プロジェクトのTopページへ 前のページへ レポートの見方 pg_make_report.plで出力されるレポートの、サマリ部分についての見方を記述します。なお、基本的に出力される情報は 指定された2つ(もしくは範囲中の最新と最古)のスナップショットの差分値ですが、一部は最新値や平均値を使用しています。 各項目でそれぞれどの値になるのかは、項目の先頭に付与されている下記の凡例を参考にして下さい。 [d]:差分値 [n]:最新値 [a]:平均値 [m]:最大値 サマリは以下のカテゴリの情報が確認できます。 レポート情報 ホスト情報 デバイス使用率 ロングトランザクション情報 DBロードプロファイル DB設定情報 (ver1.1-)消費時間の多いSQL上位10 (ver1.1-)消費時間の多い関数上位10 断片化が進んだテーブル上位
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
処理を実行中です
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く