Re: [PERFORM] JOIN order, 15K, 15K, 7MM rows

2004-06-08 Thread andrew
EXPLAIN
INSERT INTO public.historical_price ( security_serial_id, [7 fields of proprietary 
data])
SELECT public.security_series.security_serial_id, [7 fields of data],
FROM obsolete.datadb_fix INNER JOIN (obsolete.calcdb INNER JOIN public.security_series 
ON obsolete.calcdb.serial=public.security_series.legacy_calcdb_id) ON 
obsolete.datadb_fix.id=public.security_series.legacy_calcdb_id;

datadb_fix is about 5.5MM records. The other two tables are about 15K records.

 Hash Join  (cost=1151.63..225863.54 rows=5535794 width=53)
   Hash Cond: ("outer".id = "inner".serial)
   ->  Seq Scan on datadb_fix  (cost=0.00..121867.99 rows=6729299 width=28)
   ->  Hash  (cost=1115.54..1115.54 rows=14438 width=25)
 ->  Hash Join  (cost=609.96..1115.54 rows=14438 width=25)
   Hash Cond: ("outer".legacy_calcdb_id = "inner".serial)
   ->  Seq Scan on security_series  (cost=0.00..247.40 rows=15540 width=13)
   ->  Hash  (cost=572.37..572.37 rows=15037 width=12)
 ->  Seq Scan on calcdb  (cost=0.00..572.37 rows=15037 width=12)

pim_new-# Table "obsolete.datadb_fix"
pim_new-#Column|   Type   | Modifiers
pim_new-# -+--+---
pim_new-#  serial  | integer  |
pim_new-#  id  | integer  |
pim_new-#  date| date |
[4 fields deleted]
pim_new-# Indexes: sb_data_pkey unique btree (id, date),
pim_new-#  datadb1_id btree (id),


pim_new=# \d obsolete.calcdb
  Table "obsolete.calcdb"
   Column   | Type |   Modifiers

+--+
---
 serial | integer  | not null default nextval('"calcdb_s
erial_seq"'::text)
[...30 proprietary fields]

Indexes: calcdb_serial_key unique btree (serial),
[...5 other indexes]

pim_new=# \d security_series
Table "public.security_series"
   Column   | Type | Modifiers
+--+---
 security_serial_id | integer  | not null
 period | character(1) | not null
 legacy_calcdb_id   | integer  |
Indexes: security_series_pkey primary key btree (security_serial_id, period),
 secseries_legacy_id_idx1 btree (legacy_calcdb_id)

The target table has three indexes on it, so I suppose that accounts for SOME extra 
time. I ended up cancelling the query, running the select on a faster machine into an 
unindexed temp table, then using COPY out and in. That process took about 2.5 hours 
total. Machine: Linux, PG 7.3.4, 1.1GHz, 768MB RAM, unfortunately running other stuff. 
The first try which didn't finish in 24 hours was on Mac OS X Jaguar, PG 7.3.3, 1GHz, 
256MB (please don't laugh). Yes, hardware upgrades are coming, but I need to estimate 
how much more I have to squeeze out of the DB and client applications.

---(end of broadcast)---
TIP 6: Have you searched our list archives?

   http://archives.postgresql.org


Re: [PERFORM] JOIN order, 15K, 15K, 7MM rows

2004-02-22 Thread Josh Berkus
Andrew,

> I'm running and INSERT INTO ... SELECT query with this join (one record
> added per record in join), 4 hours down and all I have to show for it is
> 100 recycled transaction logs. ?
>
> If it ever returns, I can post the Explain output.

How about giving us the query and the regular EXPLAIN output right now?  I've 
a feeling that you have an unconstrained join in the query somewhere.

-- 
Josh Berkus
Aglio Database Solutions
San Francisco

---(end of broadcast)---
TIP 2: you can get off all lists at once with the unregister command
(send "unregister YourEmailAddressHere" to [EMAIL PROTECTED])