Andrew Sullivan wrote:
> On Tue, Oct 28, 2003 at 01:09:36AM -0500, Bruce Momjian wrote:
>> I am grouping the above two items together --- I thought the idea was to
>> give people a way to load 7.4 in a fairly rapid manner --- we now have
>> the ability to do ALTER TABLE ADD CONSTRAINT, but it lacks ANALYZE
>> statistics, so it is kind of slow --- perhaps nothing can be done about
>> this. Should we try to gather some statistics before doing the ALTER
>> TABLE ADD CONSTRAINT queries if no stats exist? I am not advocating it,
>> but just asking. Should COPY update the row count? Would that help?
>
> Maybe this is something to point out in the upgrading documents since
> that way it seems it could be put off to the next release? It sure
> sounds like a feature, and one about which there still seems to be
> fair disagreement. It would indeed be nice, but it doesn't sound
> like a show stopper to me if the proposal doesn't have anyone turning
> up with the code to back it.
It has to be put into the docs either way, as there still IS sort of a
possibility for the DBA to get the data in without being checked.
Version 7.4 pg_dump still has the --disable-triggers option, which only
works for data-only dumps. So if someone want's to upgrade without
running fkey checks
v74/bin/pg_dump -d $dbname >$dbname.schema.sql v74/bin/pg_dump -a --disable-triggers $dbname >$dbname.data.sql
then install 7.4, initdb and let psql slurp it up. It will loose some
performance because of building the indexes during data load instead of
CREATE INDEX after it. But I think it's still better than combing
through millions of fkey references.
Jan
--
#======================================================================#
# It's easier to get forgiveness for being wrong than for being right. #
# Let's break this rule - forgive me. #
#================================================== JanWieck@Yahoo.com #
