Re: pg_dump native format will not restore correctly
От | Sam Mason |
---|---|
Тема | Re: pg_dump native format will not restore correctly |
Дата | |
Msg-id | 20091105155002.GU5407@samason.me.uk обсуждение исходный текст |
Ответ на | Re: pg_dump native format will not restore correctly ("Scot Kreienkamp" <SKreien@la-z-boy.com>) |
Ответы |
Re: pg_dump native format will not restore correctly
Re: pg_dump native format will not restore correctly |
Список | pgsql-general |
On Thu, Nov 05, 2009 at 10:41:54AM -0500, Scot Kreienkamp wrote: > Here's the query in the sandbox: > psql -U postgres -d rms-prod -c "explain select * from soldtrx" > QUERY PLAN > -------------------------------------------------------------------- > Seq Scan on soldtrx (cost=0.00..223459.51 rows=4833151 width=278) > (1 row) > > Another strange thing I just found when composing this email... If I set > limit 5 on the query it works on the soldtrx table, but if I don't set a > limit it just hangs. That's to be expected; it's trying to copy all 5 million rows into the psql process and that'll take a while. I presume you weren't trying a similar test on the original box as you'd have got exactly the same thing. Running COUNT(*) on the table is probably a better way to make sure you've got all the rows you'd expect in there as you'll only have to copy a single row over to psql--it'll still take a while for PG to churn through things though. iostat or vmstat are good tools to see what the database box is doing while it's working. -- Sam http://samason.me.uk/
В списке pgsql-general по дате отправления: