Bagaimana saya bisa memasukkan data umum ke tabel temp dari skema yang berbeda?

Pertama, Anda dapat membuat VIEW untuk menyediakan fungsi ini:

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;

Anda dapat menanyakan tampilan ini seperti tabel lainnya:

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

source diperlukan jika order_nr tidak unik. Bagaimana lagi Anda menjamin nomor pesanan unik dari sumber yang berbeda?
Sebuah timestamp without time zone adalah ambigu dalam konteks global. Ini hanya baik sehubungan dengan zona waktunya. Jika Anda mencampur timestamp dan timestamptz , Anda perlu menempatkan timestamp pada zona waktu tertentu dengan AT TIME ZONE membangun untuk membuat ini bekerja. Untuk penjelasan lebih lanjut baca jawaban terkait ini .

Saya menggunakan UTC sebagai zona waktu, Anda mungkin ingin memberikan zona waktu yang berbeda. Pemeran sederhana "OrderDate"::timestamptz akan menganggap zona waktu Anda saat ini. AT TIME ZONE diterapkan ke timestamp menghasilkan timestamptz . Itu sebabnya saya tidak menambahkan pemeran lain.
Sementara Anda bisa , saya menyarankan untuk tidak menggunakan pengidentifikasi kasus unta di PostgreSQL sekali pun . Menghindari berbagai macam kemungkinan kebingungan. Perhatikan pengidentifikasi huruf kecil (tanpa tanda kutip ganda yang sekarang tidak perlu) yang saya berikan.
Jangan gunakan varchar(25) sebagai jenis untuk order_nr . Cukup gunakan text tanpa pengubah panjang sewenang-wenang jika harus berupa string. Jika semua nomor pesanan hanya terdiri dari digit, integer atau bigint akan lebih cepat.

Kinerja

Salah satu cara untuk mempercepat ini adalah dengan mewujudkan tampilan. Yaitu, tuliskan hasilnya ke dalam tabel (sementara):

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);

Anda membutuhkan sebuah indeks. Dalam contoh saya, batasan kunci utama menyediakan indeks secara otomatis.

Jika tabel Anda besar, pastikan Anda memiliki cukup buffer sementara untuk menangani ini di RAM sebelum Anda membuat tabel temp. Jika tidak, itu akan memperlambat Anda.

SET temp_buffers = 1000MB;

Harus menjadi panggilan pertama ke objek temp di sesi Anda. Jangan setel tinggi secara global, hanya untuk sesi Anda. Tabel sementara dijatuhkan secara otomatis di akhir sesi Anda.

Untuk mendapatkan perkiraan berapa banyak RAM yang Anda butuhkan, buat tabel sekali dan ukur:

SELECT pg_size_pretty(pg_total_relation_size('tmp_orders'));

Selengkapnya tentang ukuran objek di bawah pertanyaan terkait di dba.SE ini .

Semua overhead hanya membayar jika Anda harus memproses sejumlah kueri dalam satu sesi. Untuk kasus penggunaan lain ada solusi lain. Jika Anda mengetahui tabel sumber pada saat kueri, akan jauh lebih cepat untuk mengarahkan kueri Anda ke tabel sumber. Jika tidak, saya akan mempertanyakan keunikan order_nr Anda sekali lagi. Jika memang benar-benar unik, Anda bisa meletakkannya di kolom source saya perkenalkan.

Untuk hanya satu atau beberapa kueri, mungkin lebih cepat menggunakan tampilan daripada tampilan yang terwujud.

Saya juga akan mempertimbangkan fungsi plpgsql yang menanyakan satu tabel setelah yang lain sampai catatan ditemukan. Mungkin lebih murah untuk beberapa pertanyaan, mengingat overhead. Indeks untuk setiap tabel tentu saja dibutuhkan.

Juga, jika Anda tetap menggunakan text atau varchar untuk order_nr . Anda , pertimbangkan COLLATE "C" untuk itu.