On Sat, 20 Jun 2009, Simon Riggs wrote:
At the time, I also proposed a "filled buffer list" change to bufmgr to
allow bgwriter to preferentially target COPY's filled blocks, which
would also help with this effect.
One of the things I keep meaning to investigate is whether there's any
benefit
On Fri, 19 Jun 2009, Stefan Kaltenbrunner wrote:
In my case both the CPU (an Intel E5530 Nehalem) and the IO subsystem
(8GB Fiberchannel connected NetApp with 4GB cache) are pretty fast.
The server Alan identified as "Solaris 10 8/07 s10x_u4wos_12b X86" has a
Xeon E5320 (1.86GHz) and a single
On Fri, 2009-06-19 at 14:11 -0400, Tom Lane wrote:
> Stefan Kaltenbrunner writes:
> > ok after a bit of bisecting I'm happy to announce the winner of the contest:
> > http://archives.postgresql.org/pgsql-committers/2008-11/msg00054.php
>
> > this patch causes a 25-30% performance regression for
Merlin Moncure writes:
> I'm getting a failed assertion on 8.4b1. With cassert off it crashes
> the postmaster. The assertion is:
> ERROR: array size exceeds the maximum allowed (134217727)
Could we have a complete example, not just part of one?
regards, tom lane
--
On Fri, Jun 19, 2009 at 5:27 PM, Merlin Moncure wrote:
> I'm getting a failed assertion on 8.4b1. With cassert off it crashes
correction: I'm getting this on 8.4rc1 :-).
merlin
--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:
http://ww
I'm getting a failed assertion on 8.4b1. With cassert off it crashes
the postmaster. The assertion is:
ERROR: array size exceeds the maximum allowed (134217727)
Here is the query:
select * from (select generate_series(1,500) as id) c left outer
join foo_status a on c.id = a.id;
note: replaci
On Wed, Jun 17, 2009 at 3:44 AM, Kevin Grittner wrote:
> Andrew Dunstan wrote:
>
> > If a table is created or truncated in the same transaction that does
> > the load, and archiving is not on, the COPY is not WALed.
>
> Slightly off topic, but possibly relevant to the overall process:
> those ar
On Sat, Jun 20, 2009 at 2:06 AM, Alvaro Herrera
wrote:
> About the comment in chomp: did you try to use different values of $/?
>
>
Nope.. I think my first mail in this thread declared me a noob in perl :).
So I'd appreciate if someone could improve it perl-wise.
Thanks and best regards,
--
Lets
so 4096 * 1024 / BLCKSZ seems to be the sweet spot and also results in
more or less the same performance that 8.3 had.
Can some folks test this with different size COPYs? That's both
larger/smaller tables, and larger/smaller rows. We should also test
copy with large blob data.
--
Josh B
About the comment in chomp: did you try to use different values of $/?
--
Alvaro Herrerahttp://www.CommandPrompt.com/
The PostgreSQL Company - Command Prompt, Inc.
--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subsc
On Mon, Jun 15, 2009 at 10:00 PM, David Fetter wrote:
> On Mon, Jun 15, 2009 at 11:34:38AM -0400, Tom Lane wrote:
> > David Fetter writes:
> > > * It's going to a lot of trouble to allow for the possibility of both
> > > unordered results and of duplicate lines. If we disallow duplicate
> > >
On Friday 19 June 2009 19:12:50 Tom Lane wrote:
> Well, at the time I thought that WITH would only be a sub-clause of
> SELECT. The idea that we might allow it to be attached to INSERT etc
> causes me to revise my opinion a bit. Do you have a preference one
> way or the other about how to do this
Tom Lane wrote:
Stefan Kaltenbrunner writes:
ok after a bit of bisecting I'm happy to announce the winner of the contest:
http://archives.postgresql.org/pgsql-committers/2008-11/msg00054.php
this patch causes a 25-30% performance regression for WAL logged copy,
however in the WAL bypass case
Stefan Kaltenbrunner writes:
> ok after a bit of bisecting I'm happy to announce the winner of the contest:
> http://archives.postgresql.org/pgsql-committers/2008-11/msg00054.php
> this patch causes a 25-30% performance regression for WAL logged copy,
> however in the WAL bypass case (maybe that
On Fri, Jun 19, 2009 at 07:49:31PM +0200, Stefan Kaltenbrunner wrote:
> Tom Lane wrote:
>> Just eyeing the code ... another thing we changed since 8.3 is to enable
>> posix_fadvise() calls for WAL. Any of the complaints want to try diking
>> out this bit of code (near line 2580 in
>> src/backend/
Tom Lane wrote:
Just eyeing the code ... another thing we changed since 8.3 is to enable
posix_fadvise() calls for WAL. Any of the complaints want to try diking
out this bit of code (near line 2580 in src/backend/access/transam/xlog.c)?
#if defined(USE_POSIX_FADVISE) && defined(POSIX_FADV_DONTN
Peter Eisentraut writes:
> On Thursday 18 June 2009 23:15:53 Tom Lane wrote:
>> BTW, as far as that particular point goes: maybe we could fix the tools
>> issues underlying this, but I'm tempted to think that it's not worth the
>> trouble, because making these man pages be aliases for SELECT is ju
Tom Lane wrote:
Just eyeing the code ... another thing we changed since 8.3 is to enable
posix_fadvise() calls for WAL. Any of the complaints want to try diking
out this bit of code (near line 2580 in src/backend/access/transam/xlog.c)?
#if defined(USE_POSIX_FADVISE) && defined(POSIX_FADV_DONTN
On Thursday 18 June 2009 23:15:53 Tom Lane wrote:
> I wrote:
> > One thing I notice is that the "table" and "with" entries are not coming
> > out as intended. The file names are all caps:
> >
> > -rw-r--r-- 1 tglusers 18 Jun 12 01:37 WITH.7
> > -rw-r--r-- 1 tglusers
On Thursday 18 June 2009 22:48:53 Tom Lane wrote:
> Peter Eisentraut writes:
> > I noticed that the rc1 tarball does not contain man pages for
> > CREATE/ALTER/DROP FOREIGN DATA WRAPPER/SERVER/USER MAPPING.
>
> Just eyeballing the files, I notice that those ref pages seem not
> to contain this boi
Just eyeing the code ... another thing we changed since 8.3 is to enable
posix_fadvise() calls for WAL. Any of the complaints want to try diking
out this bit of code (near line 2580 in src/backend/access/transam/xlog.c)?
#if defined(USE_POSIX_FADVISE) && defined(POSIX_FADV_DONTNEED)
if (!
Andrew Dunstan wrote:
Kevin Grittner wrote:
8.3.7
real0m24.249s
real0m24.054s
real0m24.361s
8.4rc1
real0m33.503s
real0m34.198s
real0m33.931s
Ugh. This looks like a poster child case for a benchfarm ...
indeed...
Is there any chance you guys could trian
On 6/19/09, Andrew Dunstan wrote:
> Kevin Grittner wrote:
> > 8.3.7
> > real0m24.249s
> > real0m24.054s
> > real0m24.361s
> > 8.4rc1
> > real0m33.503s
> > real0m34.198s
> > real0m33.931s
>
> Ugh. This looks like a poster child case for a benchfarm ...
>
> Is there any
Kevin Grittner wrote:
8.3.7
real0m24.249s
real0m24.054s
real0m24.361s
8.4rc1
real0m33.503s
real0m34.198s
real0m33.931s
Ugh. This looks like a poster child case for a benchfarm ...
Is there any chance you guys could triangulate this a bit? Good initial
tria
Rajdeep Das writes:
> I am running postgresql 8.1 on winows 2003 R2 in a production scenario.
Don't do that. 8.1 for Windows was declared obsolete quite some time
ago. We are only supporting 8.2 and up.
regards, tom lane
--
Sent via pgsql-hackers mailing list (pgsql-h
Yes, you are right. I thought that they were absolute function
counts. The data makes more sense now.
Regards,
Ken
On Thu, Jun 18, 2009 at 07:03:34PM -0500, Kevin Grittner wrote:
> Kenneth Marshall wrote:
>
> > What is not clear from Stefen's function listing is how the 8.4
> > server could i
Dear Sir/Madam
I am running postgresql 8.1 on winows 2003 R2 in a production scenario. I am
getting the following error from my java application while trying to connect
to postgresql.
org.postgresql.util.PSQLException: FATAL: semctl(9335088, 3, SETVAL, 0)
failed: A non-blocking socket operati
It doesn't look like it's related to autovacuum. I re-ran the test against
the two solaris boxes with autovacuum turned off and the results look about
the same.
8.3.7 - Solaris 10 11/06 s10x_u3wos_10 X86
real0m43.662s
user0m0.001s
sys 0m0.003s
real0m43.565s
user0m0.001s
sys
On Sun, 7 Jun 2009, Peter Eisentraut wrote:
On Wednesday 03 June 2009 01:55:48 Andrew Dunstan wrote:
Running recursive grep on a subversion working copy is quite nasty.
I suggest
export GREP_OPTIONS='-d skip -I --exclude=*.svn-base --exclude=tags
--exclude=*~ --exclude-dir=CVS --exclude-dir=
29 matches
Mail list logo
