On 27/02/2010 07:52, Gokulakannan Somasundaram wrote:
Tom,
I just took the patch, but it seems to be in binary format. Can you send
me the patch to me?
gunzip shuould do the trick
Thanks,
Gokul.
On Sat, May 30, 2009 at 3:12 AM, Tom Lanet...@sss.pgh.pa.us wrote:
Josh
I don't see this as every having been applied. What should we do with
it?
---
Tom Lane wrote:
Josh Berkus j...@agliodbs.com writes:
Tom,
Is anyone interested enough to try it if I code it?
If you're patient for
Bruce Momjian br...@momjian.us writes:
I don't see this as every having been applied. What should we do with
it?
I believe we decided that there wasn't any measurable win.
regards, tom lane
--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make
Tom,
I just took the patch, but it seems to be in binary format. Can you send
me the patch to me?
Thanks,
Gokul.
On Sat, May 30, 2009 at 3:12 AM, Tom Lane t...@sss.pgh.pa.us wrote:
Josh Berkus j...@agliodbs.com writes:
Tom,
Is anyone interested enough to try it if I code it?
If
Josh Berkus j...@agliodbs.com writes:
Tom,
Is anyone interested enough to try it if I code it?
If you're patient for results, sure. I seem to be doing a customer
migration or upgrade every week now, so it wouldn't take me long to have
a test subject with a fairly complex database.
Here's
Tom,
Here's a draft patch that does ordering using two lists, as I proposed.
Please test to see if it's any faster or slower than the original logic.
Great. I'll need to get permission from a client; I can't host large
enough/complex enough databases on my own system. :-(
--
Josh Berkus
Josh Berkus j...@agliodbs.com writes:
Andrew's latest algorithm tends to result in building indexes on the
same table at the same time. This is excellent for most users; I'm on a
client's site which is I/O bound and that approach is speeding up
parallel load about 20% compared to the beta1
Tom Lane wrote:
Josh Berkus j...@agliodbs.com writes:
Andrew's latest algorithm tends to result in building indexes on the
same table at the same time. This is excellent for most users; I'm on a
client's site which is I/O bound and that approach is speeding up
parallel load about 20%
Andrew Dunstan and...@dunslane.net writes:
Tom Lane wrote:
I don't want to mess with it right now either, but perhaps we should
have a TODO item to improve the intelligence of parallel restore so that
it really does try to do things this way.
Other things being equal it schedules things in
Tom Lane wrote:
Andrew Dunstan and...@dunslane.net writes:
Tom Lane wrote:
I don't want to mess with it right now either, but perhaps we should
have a TODO item to improve the intelligence of parallel restore so that
it really does try to do things this way.
Other things
Andrew Dunstan and...@dunslane.net writes:
Tom Lane wrote:
Based on this thought, what seems to make sense as a quick-and-dirty
answer is to make sure that items get scheduled in the same order they
came free from dependency restrictions. I don't recall whether that
is true at the moment, or
Tom,
Is anyone interested enough to try it if I code it?
If you're patient for results, sure. I seem to be doing a customer
migration or upgrade every week now, so it wouldn't take me long to have
a test subject with a fairly complex database.
--
Josh Berkus
PostgreSQL Experts Inc.
Andrew, Tom,
Just wanted to remark on my tests of this feature since the last set of
patches.
First of all, no locking. Yay.
Andrew's latest algorithm tends to result in building indexes on the
same table at the same time. This is excellent for most users; I'm on a
client's site which is
13 matches
Mail list logo
