From: | Chris Browne <cbbrowne(at)acm(dot)org> |
---|---|
To: | pgsql-general(at)postgresql(dot)org |
Subject: | Re: Slony v. DBMirror |
Date: | 2005-05-06 16:09:14 |
Message-ID: | 60fyx0wd3p.fsf@dba2.int.libertyrms.com |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-general |
threshar(at)torgo(dot)978(dot)org (Jeff -) writes:
> On May 5, 2005, at 5:03 PM, Grant McLean wrote:
>>
>> Why would you need to take anything down to run pg_dump? And surely
>> bringing a slave up to speed using Slony would be much slower than
>> dump/restore?
>>
>
> You'd need to stop client access to PG to prevent changes from
> occuring between when you take the dump & when you restore on the
> slave and hten fire up dbmirror. Although it might work if you
> install the dbmirror triggers, then dump & restore.
>
> Slony uses the COPY interface to read/load data. This is the same
> method used by pg_dump so the only throttle will be the network.
There unfortunately is another throttle, at this point.
If you use pg_dump to copy a database from here to there, the
processing takes place thus:
drop index i_a on a;
drop index ii_a on a;
drop table a;
create table a ( stuff );
copy a from stdin;
...
\.
create index i_a on a (id);
create index ii_a on a (txn_date);
In that arrangement, all the data is copied, then the indexes are
generated.
The Slony-I arrangement presently rearranges it thus:
drop index i_a on a;
drop index ii_a on a;
drop table a;
create table a ( stuff );
create index i_a on a (id);
create index ii_a on a (txn_date);
copy a from stdin;
...
\.
The indices are constructed concurrently with loading the data, which
isn't nearly as fast as creating the indices afterwards.
Once Slony-I 1.1 is out, I want to start looking at how to regenerate
the indexes rather than "building into them," so as to use the
following approach:
-- Start with schema complete with indexes
drop index i_a on a;
drop index ii_a on a;
copy a from stdin;
...
\.
create index i_a on a (id);
create index ii_a on a (txn_date);
That would indeed improve performance at set creation time.
What I need, for that, is a way of grabbing all the index definitions
for the table. One way to do that would be to run "pg_dump -s -t a",
though I'd rather have a method that uses the connection I already
have to the database.
This may involve some more-or-less involved queries on pg_index,
unless the pg_indexes view is available on all versions of PG of
interest...
--
(format nil "~S(at)~S" "cbbrowne" "acm.org")
http://www.ntlug.org/~cbbrowne/sap.html
Rules of the Evil Overlord #78. "I will not tell my Legions of Terror
"And he must be taken alive!" The command will be: ``And try to take
him alive if it is reasonably practical.''"
<http://www.eviloverlord.com/>
From | Date | Subject | |
---|---|---|---|
Next Message | Andrew Sullivan | 2005-05-06 16:09:45 | Re: Slony v. DBMirror |
Previous Message | Andrew Sullivan | 2005-05-06 16:06:04 | Re: Slony v. DBMirror |