私はZeosを使ってテストしています：ZTableはフェッチ技術を使用しているのですか？Delphi、PGDac、Zeos、Fetch、Lookup？
将来的に私たちはより小さなシステムをPGSQLに移行する予定で、これは今では "テーブル"コンポーネント（BDEとして使用されていますがSQLに似たサーバーを使用しています）です。
これらの表では、実際のカーソル、つまりN個のレコードを持つ「ウィンドウ」を使用しているため、検索/検索はサーバー上で開始され、これらのN個のレコードのみが更新されます。ルックアップテーブル。
私が知っているように、PGSQLはfetch technicsを使用し、テーブル（ID int、name varchar（100））と100万レコードでテストしました。 （私もmysqlでこれを試しています）。アダプタはZeosです。
IDは、クライアント上のバイト単位で割り当てられたIDです。
MySQL
500000 2,761 113 196 344
1000000 3,214 225 471 232
313800 0,437 225 471 232
328066 0,468 225 471 232
276374 0,390 225 471 232
905984 1,264 225 471 232
260253 0,359 225 471 232
PGSQL
500000 3,042 113 188 184
1000000 3,744 225 463 064
313800 0,436 225 463 064
328066 0,452 225 463 064
276374 0,375 225 463 064
905984 1,295 225 463 064
260253 0,359 225 463 064
142023 0,203 225 463 064
あなたはレコードがローカルにフェッチされて見ての通り、これは、225メガバイトの使用状況を引き起こし、そして検索は、我々が見つけなければならないレコードがある場合に基づく、少し遅いです。
私はより多くの事を聞きたい：。
） はPGDACです我々は、メモリおよび秒でフェッチを支払わずに検索を使用することができますし、いくつかのテクニクスを持っていますか？
b。） PG ODBCドライバがADOでこの問題の解決に役立つことがありますか？ （私はADOがサーバー側のカーソルを使用できることを知っているので）？
c） ルックアップテーブルとパフォーマンスに関する経験がありますか？この重要な質問か、そうではありませんか？ （クライアントのメモリ使用量もあります）。
d） ルックアップで地獄を避けるチャンスがない場合、私たちは何ができますか？ サーバーサイド結合、およびルックアップフィールドのユニークなコードが実際のルックアップなしで変更されていますか？あなたの助けのための
ありがとう： DD
私は1つを除いてすべての私のプロジェクトのためのpostgresを使用し、私は一年前かそこらPgDacを使用してきましたし、私はパフォーマンスに満足していませんでした（ここで私はネクサス...使用）、私はUniDacを使用しています（それは無料ではありませんが、すべてのペニーに価値があります）、私はそれらを非常に満足しています。PgDacとUniDacのスピードの違いは私がPCを（倍以上のコンピューティングパワーで）切り替えたので、私はあなたにできる限り多くの質問を最適化しようとしています。しかし、PgDacからUniDacに移行したとき、 – ComputerSaysNo
UniDacはpostgreデータベースにアクセスするために追加ライブラリ（* .dll）を必要としません（これはかなり重要です）。 – ComputerSaysNo
UniDACは高速化できません両方ともUniDACのバージョンがPgDACと異なる場合にのみ例外です。 –