2009.11.09

Category: PostgreSQL / Tags:

postgreSQLでnow()とかの時間がずれている場合

amazonのEC2とかで運用すると、たぶん

#select now();

がずれると思います。チェックするところは2つ。

1.サーバの時間自体の確認(ntpdate),こちらがきちんと日本時間になっているか確認する。
2.環境変数の確認 (PGTZ の設定を確認する。)
通常、

#printenv

とかでみてみても、上記環境変数は設定されてないと思います。
.bash_profileとかに

export PGTZ=’JST-9′

を書き込んで

#source ./.bash_profile

で反映、
postmaserを再起動。
で、すると日本時間で反映されていると思います。

2009.10.19

Category: PostgreSQL / Tags:

PostgreSQL Conference 2009 Japanのお知らせ

PostgreSQL Conference 2009 Japan – JPUG 10th Anniversary Conference -
PostgreSQL の全世界の開発者と日本のユーザの交流を目指して

2009 年 11 月 20 日(金)~ 21 日(土)にAP浜松町でPostgreSQLカンファレンス
が行われます。

詳細は以下の通り。

日本PostgreSQLユーザ会設立10周年記念カンファレンス
「PostgreSQL Conference 2009 Japan」が
本日より(10月15日)よりチケット販売を開始致しました!

このカンファレンスは、例年開催している「PostgreSQL Conference」を初の国
際カンファレンスとして実施するもので、開発者と日本のユーザ様のコミュニ
ケーションの場として考えております。講演も2日間に渡り、今までで最大の応
募の中から選ばれた選りすぐりのセッションばかりです。

皆様のご来場を心よりお待ちしております。

なお、チケットは定員に達し次第締切となります。
お早目のご購入をお勧め致します。

※このメールについて
 このご案内は、自由に転送いただけます。是非ご利用ください。
————————————————————————-
PostgreSQL Conference 2009 Japan
– JPUG 10th Anniversary Conference -

日時: 2009年11月20(金),21(土) 10:00〜17:00
場所: AP浜松町(東京都港区)
主催:  日本PostgreSQLユーザ会
運営:  PostgreSQL Conference 2009 Japan 実行委員会
協賛企業:【プラチナス】SRA OSS, Inc. 日本支社
     【ゴールド】サイオステクノロジー株式会社
     【ゴールド】フォルシア株式会社
     【シルバー】Morph Labs
協力団体:オープンソースビジネス推進協議会
     日本PHPユーザ会
     新潟オープンソース協会
     日本Androidの会
日本セキュアOSユーザ会
定員:  各日240名(2日間計480名)
参加費用:Business Day(11/20) 6,500円(カンファレンス、レセプション参加)
  Community Day(11/21) 3,500円(カンファレンス、ランチつき)
申込方法:10月15日〜11月15日の間に全国のローソンにあるLoppi端末にて購入
     (ローチケ.com から予約も可能)
     購入の際には、以下のイベント名、Lコードをご利用ください。
イベント名:PostgreSQL Conference 2009
Lコード:31552
※定員になり次第締め切りますのでお早めの購入をお勧めします
参加特典:カンファレンススライド冊子(各日配布)
     協賛企業各種ノベルティ
     PostgreSQL Conference 2009 Japan オリジナルノベルティ
     レセプションによる開発者との意見交換(11/20参加者のみ)
ランチつき(11/21参加者のみ)

※ 詳細情報は、下記URLで随時更新しております。
http://www.postgresql.jp/events/pgcon09j/j/pgcon2009j/

【プログラム:Business Day(11/20)】

プログラム詳細⇒
http://www.postgresql.jp/events/pgcon09j/j/program_1

【プログラム:Community Day(11/21)】

プログラム詳細⇒
http://www.postgresql.jp/events/pgcon09j/j/program_2

お問合せ
 PostgreSQL Conference 2009 Japan 実行委員会
 E-mail: pgcon09j at ml.postgresql.jp

2009.04.01

Category: PostgreSQL / Tags:

postgreSQLでDBのサイズを確認したい場合

vacuumedb -f (full) は、できないけど、DBの再利用領域は知りたい場合
pg_database_size と pgstattuple (contribにあります) の2つのコマンド
を使うといい
使い方は、DBに入って、
dbname=# select pg_database_size(’databasename’);
pg_database_size
——————
49801171592
dbname=#select * from pgstattuple(’tablename’);
table_len | tuple_count | tuple_len | tuple_percent | dead_tuple_count | dead_tuple_len | dead_tuple_percent | free_space | free_percent
————+————-+————+—————+——————+—————-+——————–+————+————–
1738309632 | 9737154 | 1466581672 | 84.37 | 0 | 0 | 0 | 222155348 | 12.78
(1 row)
とかでてきます、大切なのは、free_spaceの所の値、ここが再利用領域になります。
– 以下に pgstattuple のREADME( 2002/08/22 石井達夫)をつけておきます。
1. pgstattupleとは
pgstattupleは,UPDATEやDELETEで作られたテーブルのゴミ領域の大きさを,
テーブル自体の物理的な大きさに対するパーセンテージで返却します.つ
まり,返却値が大きければ,それだけゴミも多いので,vacuumをかける必
要があるという判断の助けになるわけです.これ以外にもいろいろな情報
が返ります.
test=# \x
Expanded display is on.
test=# select * from pgstattuple(’pg_proc’);
-[ RECORD 1 ]——+——-
table_len | 458752
tuple_count | 1470
tuple_len | 438896
tuple_percent | 95.67
dead_tuple_count | 11
dead_tuple_len | 3157
dead_tuple_percent | 0.69
free_space | 8932
free_percent | 1.95
各項目の説明です.
table_len – テーブルの物理的な大きさ(バイト)
tuple_count – タプル数
tuple_len – タプル長の合計(バイト)
tuple_percent – タプルの割合.table_lenに対するtuple_lenの比率.
dead_tuple_len – デッドタプル数
dead_tuple_percent – デッドタプルの割合.table_lenに対するtuple_lenの比率.
free_space – 再利用可能な領域(バイト)
free_percent – 再利用可能な領域.table_lenに対するfree_spaceの比率.
2. pgstattupleのインストール
PostgreSQLが/usr/local/pgsqlにインストール済であり,testデータベー
スにpgstattupleをインストールする場合の手順を示します.
$ make
$ make install
ユーザ定義関数を登録します.
$ psql -e -f /usr/local/pgsql/share/contrib/pgstattuple.sql test
3. pgstattupleの使い方
pgstattupleの呼び出し形式は以下です.
CREATE OR REPLACE FUNCTION pgstattuple(text) RETURNS pgstattuple_type
AS ‘MODULE_PATHNAME’, ‘pgstattuple’
LANGUAGE ‘c’ WITH (isstrict);
第一引数: テーブル名
関数の戻りはpgstattuple_type型です.
pgstattupleはテーブルにAccessShareLockしかかけないので,
pgstattuple を実行中に該当テーブルに更新や削除が発生すると,正しく
ない結果を返す可能性があります.
pgstattupleがタプルを「ゴミ」と判断する基準は,
HeapTupleSatisfiesNow()が偽を返したときです.
4. pgstattupleのライセンス条件について
pgstattuple.cの冒頭に書いてある通りです.また,pgstattuple は完全に無保
証です.pgstattuple を使用したことによって生じるいかなる結果に関して
も責任を負いません.
5. 改訂履歴
2002/09/04
SRF変更に伴い,Tom Lane が修正インターフェイスの修正を行った.
そのことをこのREADMEにも反映.
2002/08/23
SRF(Set Returning Function)を使って7.3用に書き換え.
2001/12/20 Tom Laneによる修正
Fix pgstattuple to acquire a read lock on the target table. This
prevents embarassments such as having the table dropped or truncated
partway through the scan. Also, fix free space calculation to include
pages that currently contain no tuples.
2001/10/01 PostgreSQL 7.2 用contrib moduleに登録
2001/08/30 pgstattuple バージョン 0.1リリース

postgres をインストールしてみる

RedhatES3 に Postgresql7.4.16 を install
前提で、 kerberos と openssl は、 rpmでインストールしています。
今回のコンフィガーオプションは

./configure \
–with-perl \
–with-python \
–with-pam \
–with-krb5=/usr/kerberos \
–with-openssl=/usr

とした、
–with-krb5=/usr/kerberos \
がなくて
–with-openssl=/usr
だけだと。
configure: error: header file is required for OpenSSL
とエラーがでます。
これは、 kerberos と openssl を RPM でいれて postgresql をソースから入れようと
しているため、 –with-opensslだけでは、kerberosが見つけられないことに起因
しているみたいです。
oepnsslは、kerberosサポートだけどkerberosがみつからないからエラーの感じでしょうか。
MLの

[pgsql-jp: 31348] postgresql-7.3.4 コンフィグエラー からのスレッド
http://ml.postgresql.jp/pipermail/pgsql-jp/2003-October/014910.html

[pgsql-jp: 31363] Re: postgresql-7.3.4 コンフィグエラー
http://ml.postgresql.jp/pipermail/pgsql-jp/2003-October/014925.html

が参考になります。
ここだけのりこえればあとは通常どおり

#make

#make install

でおわりです。

2007.03.09

Category: PostgreSQL / Tags:

SQL色々

特定のデータ(日付とか)の所だけを別テーブルにコピー

INSERT INTO table_backup (SELECT * FROM table WHERE date LIKE ‘2005-03-%’)

2006.10.12

Category: PostgreSQL / Tags:

max_fsm_pages についてもろもろ

max_fsm_pagesは、VACUUMによりできた空き領域を共有メモリ上で管理する最大数をページ単位で設定します。
FSM(フリースペースマップ)の1ページにつき共有メモリを6Byteを消費します。
こいつが足りないと、
vacuumdb: vacuuming database “template1″
NOTICE: number of page slots needed (85008) exceeds max_fsm_pages (80000)
HINT: Consider increasing the configuration parameter “max_fsm_pages” to a value over 85008.
とか、vacuum 中に注意をもらいます。
あと、(mlから流用)
SELECT database_size(’BenchDB’);を実行すると、
database_size
—————
694729361
という結果が返ってきますので、694729361/8192=84805.8なので、
84806以上のページ数
とか、出てくるのでここの「84806」をpostgresql.confに設定してもいいかもしれません。
最初の、vacuumeの数値は、最低値、2番目のDBのサイズから求める数値は最大値として
参考の数値とするのがいいようです。
その他、こちらのページを見ると詳しくわかります。
http://thinkit.co.jp/free/marugoto/2/1/13/
ざっくり引用するのなら、FSMは10000程度でも足りるように、VACUUMの頻度を決めていく方法
がいいみたいです。

2006.09.14

Category: PostgreSQL / Tags:

【PostgreSQLウォッチ】第30回 ベータ・テストが間近に迫ったPostgreSQL 8.2の新機能

http://itpro.nikkeibp.co.jp/
のサイトから、
Postgresql8.2では、
全文検索、Copy文の改良、複数行への同時Insert、マルチプロセッサの場合の性能改善
とかされる予定みたいです。
http://itpro.nikkeibp.co.jp/article/COLUMN/20060912/247864/

2006.08.02

Category: PHP, PostgreSQL / Tags:

addslashes()ではなくpg_escape_string()を使おう

addslashesも、pg_escape_stringも文字列をエスケープさせる関数であるが、
postgreSQLに、データを流し込む(sqlを作成する)場合は、
addslashesでなく、pg_escape_stringを使うこと。
詳しいことは面倒なので
http://itpro.nikkeibp.co.jp/article/COLUMN/20060530/239359/?ST=lin-server&P=3
で確認してほしい。
要は、エスケープの方法が違うので、pg_escape_stringのほうが安全ということです。
ちなみに、postgreSQLをより安全に使うためには、
フロントエンドとバックエンドの文字コードは合わせておいたほうがいいみたいです。
つまりは、SJISは利用するなって事です。

2006.07.28

Category: PostgreSQL / Tags:

日本語、カナなどのソートがおかしい場合 – [locale]ロケールの確認

どのDBにでもいいので次のSQLで確認してみてください。

xxxx=# show lc_collate;
lc_collate
————
C
(1 row)

ここがCでない場合、文字コードによっては、ソートが上手くいかない場合があります。
ちなみに、ロケールは、initdbをする段階で決定してしまうので、DB自体を再構築しない限りは
変更する事ができません。

Freebsd ports で postgresql8.1.3 その2

初期チューニング編
ポストグレスの場合重要になる。
shared memory 共有メモリ
semaphore セマフォ
ファイルテーブル
について、チューニングです。参考はシーラカンス本
今回のマシンのメモリが512Mなので、
128MBを共有メモリとして割り当てる予定で。
-su-2.05b# ipcs -M
shminfo:
shmmax: 33554432 (max shared memory segment size)
shmmin: 1 (min shared memory segment size)
shmmni: 192 (max number of shared memory identifiers)
shmseg: 128 (max shared memory segments per process)
shmall: 8192 (max amount of shared memory in pages)
shmmax: 33554432 = 32MB
なので、
options “SHMMAX=(SMMAXPGS*PAGE_SIZE+1)”
options SHMMAXPGS = n
とするために
PAGE_SIZE は通常4096らしいので
SHMMAX を 128M(1024*1024*128=134217728)にするために
134217728 = n * 4096+1
をといて(1はとりあえず無視します。)
n = 32768
なので、 n = 32768
を設定します。
ユーザー数は、
確認(便宜上上から数値をつけてます。)
-su-2.05b# ipcs -S
seminfo:
1 semmap: 30 (# of entries in semaphore map)
2 semmni: 10 (# of semaphore identifiers)
3 semmns: 60 (# of semaphores in system)
4 semmnu: 30 (# of undo structures in system)
5 semmsl: 60 (max # of semaphores per id)
6 semopm: 100 (max # of operations per semop call)
7 semume: 10 (max # of undo entries per process)
8 semusz: 92 (size in bytes of undo structure)
9 semvmx: 32767 (semaphore maximum value)
10 semaem: 16384 (adjust on exit max value)
3の、セフォマの数(semmns)が、PostgreSQLのユーザー
semmni:
semmns: 60 (# of semaphores in system)

« Older Entries