異なるスキーマから一時テーブルに共通データを挿入するにはどうすればよいですか？

まず、 VIEWを作成できます。この機能を提供するには：

CREATE VIEW orders AS
SELECT '1'::int            AS source -- or any other tag to identify source
      ,"OrderNumber"::text AS order_nr
      ,"InvoiceNumber"     AS tansaction_id -- no cast .. is int already
      ,"OrderDate" AT TIME ZONE 'UTC' AS purchase_date -- !! see explanation
FROM   tbl_newegg

UNION  ALL  -- not UNION!
SELECT 2
       "amazonOrderId"
      ,"merchant-order-id"
      ,"purchase-date"
FROM   tbl_amazon;

このビューは、他のテーブルと同じようにクエリできます：

SELECT * FROM orders WHERE order_nr = 123 AND source = 2;

source order_nrの場合に必要ですユニークではありません。さまざまなソースで一意の注文番号を保証する方法は他にありますか？
timestamp without time zone グローバルなコンテキストではあいまいです。それはそのタイムゾーンに関連してのみ良いです。 timestampを混在させる場合およびtimestamptz 、timestampを配置する必要があります AT TIME ZONEを使用して特定のタイムゾーンでこれを機能させるために構築します。詳細については、この関連する回答をご覧ください。。

私はタイムゾーンとしてUTCを使用していますが、別のタイムゾーンを提供することをお勧めします。単純なキャスト"OrderDate"::timestamptz 現在のタイムゾーンを想定します。 AT TIME ZONE timestampに適用されます結果はtimestamptz 。そのため、別のキャストを追加しませんでした。
できる 、PostgreSQLではキャメルケース識別子を使用しないことをお勧めします。考えられるさまざまな混乱を回避します。私が提供した小文字の識別子（今は不要な二重引用符なし）に注意してください。
varchar(25)は使用しないでください order_nrのタイプとして。 textを使用するだけです文字列である必要がある場合は、任意の長さ修飾子なし。すべての注文番号が数字のみで構成されている場合は、integer またはbigint 速くなります。

パフォーマンス

これを高速化する1つの方法は、ビューを具体化することです。つまり、結果を（一時的な）テーブルに書き込みます：

CREATE TEMP TABLE tmp_orders AS
SELECT * FROM orders;

ANALYZE tmp_orders; -- temp tables are not auto-analyzed!

ALTER TABLE tmp_orders
ADD constraint orders_pk PRIMARY KEY (order_nr, source);

必要インデックス。私の例では、主キー制約がインデックスを自動的に提供します。

テーブルが大きい場合は、十分な一時バッファがあることを確認してください。前のRAMでこれを処理する一時テーブルを作成します。そうでなければ、実際には速度が低下します。

SET temp_buffers = 1000MB;

セッション内の一時オブジェクトへの最初の呼び出しである必要があります。セッションのためだけに、グローバルに高く設定しないでください。とにかく、一時テーブルはセッションの終了時に自動的に削除されます。

必要なRAMの量を見積もるには、テーブルを1回作成して、次のように測定します。

SELECT pg_size_pretty(pg_total_relation_size('tmp_orders'));

このdba.SEに関する質問でのオブジェクトサイズの詳細。

すべてのオーバーヘッドは、1つのセッション内で多数のクエリを処理する必要がある場合にのみ支払われます。他のユースケースについては、他の解決策があります。クエリの時点でソーステーブルがわかっている場合は、代わりにソーステーブルにクエリを送信する方がはるかに高速です。そうでない場合は、order_nrの一意性に疑問があります。もう一度。実際、一意であることが保証されている場合は、source列を削除できます。紹介しました。

1つまたは少数のクエリの場合、マテリアライズドビューの代わりにビューを使用する方が速い場合があります。

plpgsql関数も検討しますレコードが見つかるまで、次々にテーブルを照会します。オーバーヘッドを考慮すると、いくつかのクエリの方が安くなる可能性があります。もちろん、必要なすべてのテーブルのインデックス。

また、textに固執する場合またはvarchar order_nrの場合、COLLATE "C"