Clinging to sanity, oneway_111@yahoo.com (ow) mumbled into her beard:
> --- Tom Lane <tgl@sss.pgh.pa.us> wrote:
>> > Wouldn't the above put a limit on a number of records one could have
>> > in table?
>>
>> No.
>
> If I understand correctly, a table that has 4B+ rows cannot be restored after
> the dump and that, in turn, may/will affect the ability to upgrade to new
> versions of pgSql.
>
> This is somewhat similar to saying "yes" to the question "Can I drive this car
> at 55 mph?" and then forgetting to mention that the brakes will fail if the car
> reaches 55 mph.
No, you are NOT understanding correctly.
Restoring a table from pg_dump generally involves _ONE_ command.
For instance, the following is what pg_dump generates for my table, "stocks."
COPY stocks (symbol, description, exchange) FROM stdin;
AADBX AADBX NYSE
AADEX AADEX NYSE
AAIEX AAIEX NYSE
BTS.A BTS.A TSX
CTSTK TD Canadian Equity CTE
CASH CASH TSX
CTAMER TD AmeriGrowth RSP CTE
CTASIA TD AsiaGrowth RSP CTE
CTEMER TD Emerging Markets RSP CTE
CTEURO TD European Growth RSP CTE
CTIBND TD Global RSP Bond CTE
FDIVX FDIVX NYSE
FDRXX FDRXX NYSE
FUSEX FUSEX NYSE
MOT MOT NYSE
NCX NOVA Chemicals Corporation TSX
NT NT NYSE
PCA Petro Canada TSX
RY Royal Bank of Canada TSX
TOC Thomson Corporation TSX
TRP TransCanada PipeLines Limited TSX
WORKVE Working Ventures OTHER
CTSPEC TD SPECIAL EQUITY CTE
CTUSEQ TD US EQUITY CTE
CTMM TD MONEY MARKET PL CTE
CTCBOND TD Canadian Bond CTE
\.
Recovery from this involves the SQL processor using ONE transaction
ID, and ONE SQL statement. If there were 8 billion rows in the table,
whatever other challenges there might be, it would still use ONE
transaction ID and ONE SQL statement.
What is there about "This involves just one SQL statement" that isn't
making sense?
--
wm(X,Y):-write(X),write('@'),write(Y). wm('cbbrowne','acm.org').
http://www.ntlug.org/~cbbrowne/lisp.html
Pagers are cases for holding dead batteries. -Richard Wolff
