--- Bruce Momjian <[EMAIL PROTECTED]> wrote:
> ow wrote:
> >
> > --- Bruce Momjian <[EMAIL PROTECTED]> wrote:
> > >
> > > Yep, we want to do something, but not sure what. We have:
> > >
> > > * Allow triggers to be disabled [trigger]
> > >
I think the following should be added to the "Allo
ow wrote:
>
> --- Bruce Momjian <[EMAIL PROTECTED]> wrote:
> >
> > Yep, we want to do something, but not sure what. We have:
> >
> > * Allow triggers to be disabled [trigger]
> >
>
> Will ppl remember some time from now that it also deals with FK constraints and
> pg_restore/dump options?
--- Bruce Momjian <[EMAIL PROTECTED]> wrote:
>
> Yep, we want to do something, but not sure what. We have:
>
> * Allow triggers to be disabled [trigger]
>
Will ppl remember some time from now that it also deals with FK constraints and
pg_restore/dump options?
Thanks
___
Stephan Szabo wrote:
>
> On Mon, 17 Nov 2003, ow wrote:
>
> > --- Stephan Szabo <[EMAIL PROTECTED]> wrote:
> > > Like I said, it's been discussed and I would expect some form of this for
> > > 7.5 although I can't say for certain. Enough people were interested in
> > > the discussion that it's l
On Mon, 17 Nov 2003, ow wrote:
> --- Stephan Szabo <[EMAIL PROTECTED]> wrote:
> > Like I said, it's been discussed and I would expect some form of this for
> > 7.5 although I can't say for certain. Enough people were interested in
> > the discussion that it's likely to happen with a little champ
--- Stephan Szabo <[EMAIL PROTECTED]> wrote:
> Like I said, it's been discussed and I would expect some form of this for
> 7.5 although I can't say for certain. Enough people were interested in
> the discussion that it's likely to happen with a little championing.
Does not appear like it's on th
On Mon, 17 Nov 2003, ow wrote:
> --- Stephan Szabo <[EMAIL PROTECTED]> wrote:
> > Well, I've been trying to deal with the particular case at hand, ie, get
> > your load in a more reasonable amount of time assuming that you had more
> > constraints and this was going to be a particular problem for
--- Stephan Szabo <[EMAIL PROTECTED]> wrote:
> Well, I've been trying to deal with the particular case at hand, ie, get
> your load in a more reasonable amount of time assuming that you had more
> constraints and this was going to be a particular problem for you in the
> immediate term. I've menti
On Mon, 17 Nov 2003, ow wrote:
> --- Stephan Szabo <[EMAIL PROTECTED]> wrote:
> >
> > I assume you're also not modifying the pktable rows (since that would
> > access the fk table based solely on the fk).
>
> I do modify the fk table: inserts and updates (but pk is never updated). Also
> do not de
--- Stephan Szabo <[EMAIL PROTECTED]> wrote:
>
> I assume you're also not modifying the pktable rows (since that would
> access the fk table based solely on the fk).
I do modify the fk table: inserts and updates (but pk is never updated). Also
do not delete records.
> Does the multi-field index
On Mon, 17 Nov 2003, ow wrote:
> --- Jeff <[EMAIL PROTECTED]> wrote:
> > On Mon, 17 Nov 2003 10:40:20 -0800 (PST)
> > Stephan Szabo <[EMAIL PROTECTED]> wrote:
> >
> > >
> > > By the way, what does your schema look like? I created an 80M row fk
> > > table and 20K row pk table with an int4 key be
--- Jeff <[EMAIL PROTECTED]> wrote:
> On Mon, 17 Nov 2003 10:40:20 -0800 (PST)
> Stephan Szabo <[EMAIL PROTECTED]> wrote:
>
> >
> > By the way, what does your schema look like? I created an 80M row fk
> > table and 20K row pk table with an int4 key between them and indexes on
> > the two key fie
On Mon, 17 Nov 2003, Jeff wrote:
> On Mon, 17 Nov 2003 10:40:20 -0800 (PST)
> Stephan Szabo <[EMAIL PROTECTED]> wrote:
>
> >
> > By the way, what does your schema look like? I created an 80M row fk
> > table and 20K row pk table with an int4 key between them and indexes on
> > the two key fields.
On Mon, 17 Nov 2003 10:40:20 -0800 (PST)
Stephan Szabo <[EMAIL PROTECTED]> wrote:
>
> By the way, what does your schema look like? I created an 80M row fk
> table and 20K row pk table with an int4 key between them and indexes on
> the two key fields. It took about 25 minutes on my not terribly
On Sun, 16 Nov 2003, ow wrote:
> --- ow <[EMAIL PROTECTED]> wrote:
> > Perhaps I should clarify.
> >
> > First, I ran pg_dump to extract schema and data *together*. Then I ran
> > pg_restore to restore the db. It took about 1 hour to create tables and copy
> > the data, then about 40 min to creat
--- Rudi Starcevic wrote:
> I'm not trying to upset anyone just trying to help you get an answer for your
> issues.
Who knows what you're trying to do? You did not provide any answers and why you
decided to quote the *same* email *twice* if it was sent only *once* I may
never know.
Anyway, tha
Hi ow,
When your using expensive support, like this email list, technical
replies can take some time.
Perhaps those who can help you are on the other side of the globe and
are sleeping.
Or maybe they busy trying to make a living.
Please be patient.
If you do not recieve a reply I suggest you po
--- ow <[EMAIL PROTECTED]> wrote:
> Perhaps I should clarify.
>
> First, I ran pg_dump to extract schema and data *together*. Then I ran
> pg_restore to restore the db. It took about 1 hour to create tables and copy
> the data, then about 40 min to create indexes, then pg_restore spent 4.5
> hours
On Sun, 16 Nov 2003, ow wrote:
>
> --- Stephan Szabo <[EMAIL PROTECTED]> wrote:
> > Only assuming that no changes were made between dump and restore. This
> > could be changes to schema or data done manually, but it could also be a
> > locale or possibly encoding change if you have any textual fo
--- Stephan Szabo <[EMAIL PROTECTED]> wrote:
> Only assuming that no changes were made between dump and restore. This
> could be changes to schema or data done manually, but it could also be a
> locale or possibly encoding change if you have any textual foreign keys.
I'm restoring the database,
On Sun, 16 Nov 2003, ow wrote:
> --- Peter [EMAIL PROTECTED]> wrote:
> >
> > Read again. No one was talking of pg_restore.
>
> Perhaps I should clarify.
>
> First, I ran pg_dump to extract schema and data *together*. Then I ran
> pg_restore to restore the db. It took about 1 hour to create tables
Where can we place wishes for PostgreSQL v7.5 and 8.0 ??? Is it
pgsql-hackers ???
---
Oli Sennhauser
Database-Engineer (Oracle & PostgreSQL)
Rebenweg 6
CH - 8610 Uster / Switzerland
Phone (+41) 1 940 24 82 or Mobile (+41) 79 450 49 14
e-Mail [E
--- Peter [EMAIL PROTECTED]> wrote:
>
> Read again. No one was talking of pg_restore.
Perhaps I should clarify.
First, I ran pg_dump to extract schema and data *together*. Then I ran
pg_restore to restore the db. It took about 1 hour to create tables and copy
the data, then about 40 min to crea
ow writes:
> --- Peter Eisentraut <[EMAIL PROTECTED]> wrote:
> > If you you pg_dump and dump schema and data together, then there is some
> > magic to temporarily disable foreign key constraints. Try it out.
>
> Dunno. Don't see any magic so far. In fact, pg_restore appears to use
> internally th
pgSql 7.4.rc2
--- Peter Eisentraut <[EMAIL PROTECTED]> wrote:
> If you you pg_dump and dump schema and data together, then there is some
> magic to temporarily disable foreign key constraints. Try it out.
Dunno. Don't see any magic so far. In fact, pg_restore appears to use
internally the same S
--- Peter Eisentraut <[EMAIL PROTECTED]> wrote:
> If you you pg_dump and dump schema and data together, then there is some
> magic to temporarily disable foreign key constraints. Try it out.
> Perhaps you can adopt the statements to your particular restoration method
> as well, if it turns out ne
ow writes:
> Can you clarify how this would be better than the second option I described?
> Unless pg_restore can somehow create FK constraints differently (and more
> efficiently) than using "ALTER TABLE xxx ADD CONSTRAINT", I do not see how this
> would help.
If you you pg_dump and dump schema
--- Peter Eisentraut <[EMAIL PROTECTED]> wrote:
> ow writes:
>
> > 1) dump the data only, create the table with all indexes and constraints
> (from
> > script that has nothing to do with pg_restore), import the data. The import
> > part was running for hours (14+) with no end in sight. Had to kil
ow writes:
> 1) dump the data only, create the table with all indexes and constraints (from
> script that has nothing to do with pg_restore), import the data. The import
> part was running for hours (14+) with no end in sight. Had to kill it.
Dump the data and the schema and it will do it in the
pgSql 7.4.rc2
Hi,
Am somewhat lost about how one should use pg_restore with large dbs. For
simplicity, let's assume that db has only one (1) table with huge amout of
rows. Tried several approaches:
1) dump the data only, create the table with all indexes and constraints (from
script that has not
30 matches
Mail list logo
