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 Lane wrote:
Josh Berkus writes:
Tom,
Is anyone in
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 wrote:
> Josh Berkus writes:
> > Tom,
> >> Is anyone interested enough to try it if I code it?
>
> > If you're patient for results, sur
Bruce Momjian 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 changes to you
I don't see this as every having been applied. What should we do with
it?
---
Tom Lane wrote:
> Josh Berkus writes:
> > Tom,
> >> Is anyone interested enough to try it if I code it?
>
> > If you're patient for results, su
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
P
Josh Berkus 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 a draft pat
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.
www
Andrew Dunstan 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 how hard i
Tom Lane wrote:
Andrew Dunstan 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 sched
Andrew Dunstan 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 TOC order, wh
Tom Lane wrote:
Josh Berkus 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 beta
Josh Berkus 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 version.
Hmp
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
