On Tuesday 29 December 2009 04:04:06 Michael Clemmons wrote:
> Maybe not crash out but in this situation.
> N=0
> while(N>=0):
> CREATE DATABASE new_db_N;
> Since the fsync is the part which takes the memory and time but is
> happening in the background want the fsyncs pile up in the backgroun
Maybe not crash out but in this situation.
N=0
while(N>=0):
CREATE DATABASE new_db_N;
Since the fsync is the part which takes the memory and time but is happening
in the background want the fsyncs pile up in the background faster than can
be run filling up the memory and stack.
This is very lik
On Tuesday 29 December 2009 03:53:12 Michael Clemmons wrote:
> Andres,
> Great job. Looking through the emails and thinking about why this works I
> think this patch should significantly speedup 8.4 on most any file
> system(obviously some more than others) unless the system has significantly
> re
Andres,
Great job. Looking through the emails and thinking about why this works I
think this patch should significantly speedup 8.4 on most any file
system(obviously some more than others) unless the system has significantly
reduced memory or a slow single core. On a Celeron with 256 memory I susp
On Tuesday 29 December 2009 01:46:21 Greg Smith wrote:
> Andres Freund wrote:
> > As I said the real benefit only occurred after adding posix_fadvise(..,
> > FADV_DONTNEED) which is somewhat plausible, because i.e. the directory
> > entries don't need to get scheduled for every file and because the
Andres Freund wrote:
As I said the real benefit only occurred after adding posix_fadvise(..,
FADV_DONTNEED) which is somewhat plausible, because i.e. the directory entries
don't need to get scheduled for every file and because the kernel can reorder a
whole directory nearly sequentially. Withou
On Tue, 29 Dec 2009, Andres Freund wrote:
On Tuesday 29 December 2009 01:30:17 da...@lang.hm wrote:
On Tue, 29 Dec 2009, Greg Stark wrote:
On Mon, Dec 28, 2009 at 10:54 PM, Andres Freund
wrote:
fsync everything in that pass.
Including the directory - which was not done before and actually m
On Tue, 29 Dec 2009, Greg Stark wrote:
On Mon, Dec 28, 2009 at 10:54 PM, Andres Freund wrote:
fsync everything in that pass.
Including the directory - which was not done before and actually might be
necessary in some cases.
Er. Yes. At least on ext4 this is pretty important. I wish it weren'
On Tuesday 29 December 2009 01:30:17 da...@lang.hm wrote:
> On Tue, 29 Dec 2009, Greg Stark wrote:
> > On Mon, Dec 28, 2009 at 10:54 PM, Andres Freund
wrote:
> >> fsync everything in that pass.
> >> Including the directory - which was not done before and actually might
> >> be necessary in some c
On Tuesday 29 December 2009 01:27:29 Greg Stark wrote:
> On Mon, Dec 28, 2009 at 10:54 PM, Andres Freund wrote:
> > fsync everything in that pass.
> > Including the directory - which was not done before and actually might be
> > necessary in some cases.
>
> Er. Yes. At least on ext4 this is prett
On Mon, Dec 28, 2009 at 10:54 PM, Andres Freund wrote:
> fsync everything in that pass.
> Including the directory - which was not done before and actually might be
> necessary in some cases.
Er. Yes. At least on ext4 this is pretty important. I wish it weren't,
but it doesn't look like we're goin
Michael Clemmons wrote on 11.12.2009 23:52:
Thanks all this has been a good help.
I don't have control(or easy control) over unit tests creating/deleting
databases since Im using the django framework for this job. Createdb
takes 12secs on my system(9.10 pg8.4 and ext4) which is impossibly slow
On Tuesday 29 December 2009 00:06:28 Tom Lane wrote:
> Andres Freund writes:
> > This speeds up CREATE DATABASE from ~9 seconds to something around 0.8s
> > on my laptop. Still slower than with fsync off (~0.25) but quite a
> > worthy improvement.
>
> I can't help wondering whether that's real o
On Tuesday 29 December 2009 00:06:28 Tom Lane wrote:
> Andres Freund writes:
> > This speeds up CREATE DATABASE from ~9 seconds to something around 0.8s
> > on my laptop. Still slower than with fsync off (~0.25) but quite a
> > worthy improvement.
> I can't help wondering whether that's real or s
Andres Freund writes:
> This speeds up CREATE DATABASE from ~9 seconds to something around 0.8s on my
> laptop. Still slower than with fsync off (~0.25) but quite a worthy
> improvement.
I can't help wondering whether that's real or some kind of
platform-specific artifact. I get numbers more l
On Monday 28 December 2009 23:54:51 Andres Freund wrote:
> On Saturday 12 December 2009 21:38:41 Andres Freund wrote:
> > On Saturday 12 December 2009 21:36:27 Michael Clemmons wrote:
> > > If ppl think its worth it I'll create a ticket
> >
> > Thanks, no need. I will post a patch tomorrow or so.
>
On Saturday 12 December 2009 21:38:41 Andres Freund wrote:
> On Saturday 12 December 2009 21:36:27 Michael Clemmons wrote:
> > If ppl think its worth it I'll create a ticket
> Thanks, no need. I will post a patch tomorrow or so.
Well. It was a long day...
Anyway.
In this patch I delay the fsync do
Glyn Astill wrote:
Last month I found myself taking a powerdrill to our new dell
boxes in order to route cables to replacement raid cards. Having
to do that made me feel really unprofessional and a total cowboy,
but it was either that or shitty performance.
Can you be more specific? Which Dell
"Kevin Grittner" writes:
> Tom Lane wrote:
>> The approach contemplated in the comment, of assembling some stats
>> on-the-fly from the stats for individual child tables, doesn't
>> seem real practical from a planning-time standpoint.
> Can you give a thumbnail sketch of why that is?
Well, it
Tom Lane wrote:
> Yeah, that is expected. Nestloop inner indexscans have a rowcount
> estimate that is different from that of the parent table --- the
> parent's rowcount is what would be applicable for another type of
> join, such as merge or hash, where the join condition is applied
> at the
20 matches
Mail list logo
