Hi Tom,
How much concern is there for the contention for use cases where the WAL
can't be bypassed?
Thanks, Alan
On Sun, Jun 21, 2009 at 10:00 AM, Tom Lane wrote:
> Stefan Kaltenbrunner writes:
> > The following copying 3M rows(each) into a seperate table of the same
> > database.
>
> Is this
On Mon, 22 Jun 2009, Peter Eisentraut wrote:
Well, I rarely test the actual release source tarball, so it might have
been like that forever.
'k ... I swore I haven't changed anything over there in awhile, so was
most confused as to where this sudden error came from ...
Marc G. Fournier
On Monday 22 June 2009 00:17:06 Marc G. Fournier wrote:
> On Thu, 18 Jun 2009, Tom Lane wrote:
> > Peter Eisentraut writes:
> >> I noticed that the rc1 tarball includes scanner files that are built
> >> with an older flex version that generates warnings with our default
> >> compilation flags. Sin
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
On Mon, Jun 22, 2009 at 03:16:05AM +0530, Gurjeet Singh wrote:
[...]
> [...] But it sure cost me a few cycles to
> realize that the files I copied from my Windows host to my Fedora VM were
> just not the thing perl would like.
Had it been a Windows-
KaiGai Kohei wrote:
> The todo list says, as follows:
> * Binary Data
> o Add security checks for large objects
>
> http://wiki.postgresql.org/wiki/Todo#Binary_Data
>
> Is anyone working on? or interested in?
OK, it seems to me nobody is working on the todo item.
I'll also submit this feature
Dear:
my operating system is vista.I build the postgresql using visual studio
2005, when i run the initdb ,it gives me the error like:
"It appears that your GMT time zone uses leap seconds PostgreSql does not
support leap secondds"
What can I do?
2009-06-21
rct682
On Jun 21, 2009, at 5:07 PM, David E. Wheeler wrote:
I was just looking at the documentation for cursors command, and
noticed that the MOVE command's "direction" argument doesn't seem to
have documentation for its possible values.
http://www.postgresql.org/docs/8.4/static/sql-move.html
Howdy,
I was just looking at the documentation for cursors command, and
noticed that the MOVE command's "direction" argument doesn't seem to
have documentation for its possible values.
http://www.postgresql.org/docs/8.4/static/sql-move.html
I assume that they should be FORWARD and BACK
On Sun, Jun 21, 2009 at 11:37 PM, David Fetter wrote:
> On Sun, Jun 21, 2009 at 10:36:04PM +0530, Gurjeet Singh wrote:
> > 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 $/?
> > >
> > >
> > Well, now that I h
On Thu, 18 Jun 2009, Tom Lane wrote:
Peter Eisentraut writes:
I noticed that the rc1 tarball includes scanner files that are built with an
older flex version that generates warnings with our default compilation flags.
Since I have been running with -Werror by default for a great while now, thi
On Sun, 2009-06-21 at 20:37 +0300, Heikki Linnakangas wrote:
> Robert Haas wrote:
> > On Sun, Jun 21, 2009 at 11:52 AM, Tom Lane wrote:
> >> So to my mind, the only question left to answer (at least for the 8.4
> >> cycle) is "is 16MB enough, or do we want to make the ring even bigger?".
> >> Righ
On Sun, 2009-06-21 at 12:38 -0400, Tom Lane wrote:
> Greg Stark writes:
> > There was some discussion of doing this in general for all inserts
> > inside the indexam. The btree indexam could buffer up any inserts done
> > within the transaction and keep them in an in-memory btree. Any
> > lookups
On Sun, Jun 21, 2009 at 10:36:04PM +0530, Gurjeet Singh wrote:
> 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 $/?
> >
> >
> Well, now that I have tried it, yes, setting $/ to '\r\n' does give me what
> I expected.
Tom Lane wrote:
Stefan Kaltenbrunner writes:
The following copying 3M rows(each) into a seperate table of the same
database.
Is this with WAL, or bypassing WAL? Given what we've already seen,
a lot of contention for WALInsertLock wouldn't surprise me much here.
It should be possible to bypas
Heikki Linnakangas writes:
> I was going to say that since we flush the WAL every 16MB anyway (at
> every XLOG file switch), you shouldn't see any benefit with larger ring
> buffers, since to fill 16MB of data you're not going to write more than
> 16MB WAL.
I'm not convinced that WAL segment b
Robert Haas wrote:
On Sun, Jun 21, 2009 at 11:52 AM, Tom Lane wrote:
So to my mind, the only question left to answer (at least for the 8.4
cycle) is "is 16MB enough, or do we want to make the ring even bigger?".
Right at the moment I'd be satisfied with 16, but I wonder whether there
are scenari
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 $/?
>
>
Well, now that I have tried it, yes, setting $/ to '\r\n' does give me what
I expected. Both expected and result files should have the same kind of line
endings thoug
Stefan Kaltenbrunner writes:
> The following copying 3M rows(each) into a seperate table of the same
> database.
Is this with WAL, or bypassing WAL? Given what we've already seen,
a lot of contention for WALInsertLock wouldn't surprise me much here.
It should be possible to bypass that though.
Tom Lane wrote:
Heikki Linnakangas writes:
I wonder if using the small ring showed any benefit when the COPY is not
WAL-logged? In that scenario block-on-WAL-flush behavior doesn't happen,
so the small ring might have some L2 cache benefits.
I think the notion that we might get a cache win f
Greg Stark writes:
> There was some discussion of doing this in general for all inserts
> inside the indexam. The btree indexam could buffer up any inserts done
> within the transaction and keep them in an in-memory btree. Any
> lookups done within the transaction first look up in the in-memory
>
On Sun, Jun 21, 2009 at 5:07 PM, Robert Haas wrote:
>
> I think we had the idea of buffering up enough tuples to fill a page
> (estimating conservatively so as to make sure we actually fill it),
> and then inserting them all at once. But I'm not sure how much
> trouble that causes in terms of the
On Sun, Jun 21, 2009 at 11:52 AM, Tom Lane wrote:
> Heikki Linnakangas writes:
>> I wonder if using the small ring showed any benefit when the COPY is not
>> WAL-logged? In that scenario block-on-WAL-flush behavior doesn't happen,
>> so the small ring might have some L2 cache benefits.
>
> I think
On Sun, Jun 21, 2009 at 11:31 AM, Tom Lane wrote:
> Robert Haas writes:
>> It would be interesting to see some gprof or oprofile output from that
>> test. I went back and dug up the results that I got when I profiled
>> this patch during initial development, and my version of the patch
>> applie
Heikki Linnakangas writes:
> I wonder if using the small ring showed any benefit when the COPY is not
> WAL-logged? In that scenario block-on-WAL-flush behavior doesn't happen,
> so the small ring might have some L2 cache benefits.
I think the notion that we might get a cache win from a smaller
Tom Lane wrote:
Robert Haas writes:
It would be interesting to see some gprof or oprofile output from that
test. I went back and dug up the results that I got when I profiled
this patch during initial development, and my version of the patch
applied, the profile looked like this on my system:
Robert Haas writes:
> It would be interesting to see some gprof or oprofile output from that
> test. I went back and dug up the results that I got when I profiled
> this patch during initial development, and my version of the patch
> applied, the profile looked like this on my system:
Were you
On Sun, Jun 21, 2009 at 6:48 AM, Stefan
Kaltenbrunner wrote:
> So I do think that IO is in fact not too significant for this kind of
> testing and we still have ways to go in terms of CPU efficiency in COPY.
It would be interesting to see some gprof or oprofile output from that
test. I went back
Stefan Kaltenbrunner wrote:
Simon Riggs wrote:
On Sun, 2009-06-21 at 10:28 +0200, Stefan Kaltenbrunner wrote:
I did some limited testing on that but I was unable to measure any
significant effect - especially since the difference between
wal-logged and not is rather small for a non-parallel CO
Simon Riggs wrote:
On Sun, 2009-06-21 at 10:28 +0200, Stefan Kaltenbrunner wrote:
I did some limited testing on that but I was unable to measure any
significant effect - especially since the difference between
wal-logged and not is rather small for a non-parallel COPY (ie in the
above example y
On Sun, 2009-06-21 at 02:45 -0400, Greg Smith wrote:
> On Sat, 20 Jun 2009, Simon Riggs wrote:
>
> > I would suggest that we check how much WAL has been written. There may
> > be a secondary effect or a different regression hidden in these results.
>
> What's the easiest way to do that?
pg_cur
On Sun, 2009-06-21 at 10:28 +0200, Stefan Kaltenbrunner wrote:
> I did some limited testing on that but I was unable to measure any
> significant effect - especially since the difference between
> wal-logged and not is rather small for a non-parallel COPY (ie in the
> above example you get around
Heikki Linnakangas wrote:
Tom Lane wrote:
Simon Riggs writes:
On Sat, 2009-06-20 at 13:15 +0200, Stefan Kaltenbrunner wrote:
8192 6m43.203s/6m48.293s
16384 6m24.980s/6m24.116s
32768 6m20.753s/6m22.083s
65536 6m22.913s/6m22.449s
1048576 6m23.765s/6m24.645s
The rest of the patch should have
Tom Lane wrote:
Simon Riggs writes:
On Sat, 2009-06-20 at 13:15 +0200, Stefan Kaltenbrunner wrote:
8192 6m43.203s/6m48.293s
16384 6m24.980s/6m24.116s
32768 6m20.753s/6m22.083s
65536 6m22.913s/6m22.449s
1048576 6m23.765s/6m24.645s
The rest of the patch should have had a greater effect on tab
33 matches
Mail list logo
