Bruce Momjian wrote:
pgman wrote:
I have marged Tom's description of the new sequence binding with text I
was working on. I modified it to follow the existing we used to do X,
now we do Y pattern in the surrounding entries:
http://candle.pha.pa.us/tmp/pgsql/release.html#RELEASE-8-1
Sorry,
Devrim, I had some problems installing on RedHat ES3.0 with the RPMs. This
issue turned out to be that I needed the compat libs to provide the old libs
before I could install the new libs.
I found a link to
http://developer.PostgreSQL.org/~devrim/compat-postgresql-libs-3-3PGDG.i686.rpm
in an
Why are the transaction identifiers used in the 2PC commands lexical
strings rather than identifiers? Shouldn't database objects be
identifiers and strings be purely data objects? Or is there some
standard or precedent on that?
--
Peter Eisentraut
http://developer.postgresql.org/~petere/
Hi all,
I'm the administrator of that machine and PLCheck is failing.
Is there anything I can do to fix it ?
Regards
Gaetano Mendola
---(end of broadcast)---
TIP 6: explain analyze is your friend
Index: fe-exec.c
===
RCS file: /projects/cvsroot/pgsql/src/interfaces/libpq/fe-exec.c,v
retrieving revision 1.175
diff -c -r1.175 fe-exec.c
*** fe-exec.c 24 Sep 2005 17:53:28 - 1.175
--- fe-exec.c 3 Oct 2005 12:49:08
Good people,
Just had a thought!
Might it be worth while protecting the postmaster from an OOM Kill on
Linux by setting /proc/{pid}/oom_adj to -17 ?
(Described vaguely in mm/oom_kill.c)
Kind Regards,
John Hansen
---(end of broadcast)---
TIP 1:
On Mon, Oct 03, 2005 at 11:03:06PM +1000, John Hansen wrote:
Might it be worth while protecting the postmaster from an OOM Kill on
Linux by setting /proc/{pid}/oom_adj to -17 ?
(Described vaguely in mm/oom_kill.c)
Has it actually happened to you? PostgreSQL is pretty good about its
memory
Thanks, fixed.
---
Michael Paesold wrote:
Bruce Momjian wrote:
pgman wrote:
I have marged Tom's description of the new sequence binding with text I
was working on. I modified it to follow the existing we used to
Peter Eisentraut [EMAIL PROTECTED] writes:
Why are the transaction identifiers used in the 2PC commands lexical
strings rather than identifiers? Shouldn't database objects be
identifiers and strings be purely data objects? Or is there some
standard or precedent on that?
I proposed the
Gaetano Mendola [EMAIL PROTECTED] writes:
I'm the administrator of that machine and PLCheck is failing.
Is there anything I can do to fix it ?
What version of Python have you got on that thing? It seems to be
emitting still another spelling of the encoding error message :-(
Greg Sabino Mullane [EMAIL PROTECTED] writes:
! (void) sprintf((char *) rp, %03o, *vp);
! (void) snprintf((char *) rp, 6, %03o, *vp);
Hardly looks like a critical fix, or even a needed one. Why bother?
regards, tom lane
John Hansen [EMAIL PROTECTED] writes:
Might it be worth while protecting the postmaster from an OOM Kill on
Linux by setting /proc/{pid}/oom_adj to -17 ?
(Described vaguely in mm/oom_kill.c)
(a) wouldn't that require root privilege? (b) how would we determine
whether we are on a system to
I'm not averse to it. I think it's a good option and I support trace_sort (it really is more of a trace).On 10/3/05, Tom Lane
[EMAIL PROTECTED] wrote:Simon Riggs
[EMAIL PROTECTED] writes: The following patch implements a fairly light set of timing statements aimed at understanding external sort
Simon Riggs [EMAIL PROTECTED] writes:
The following patch implements a fairly light set of timing statements
aimed at understanding external sort performance. There is no attempt to
alter the algorithms.
What do people think about putting something like this into 8.1?
Strictly speaking it's a
-Original Message-
From: [EMAIL PROTECTED]
[mailto:[EMAIL PROTECTED] On Behalf Of Tom Lane
Sent: 03 October 2005 15:37
To: Simon Riggs
Cc: pgsql-hackers@postgresql.org; pgsql-patches@postgresql.org
Subject: Re: [PATCHES] [HACKERS] External Sort timing debug
statements
Tom Lane wrote:
Gaetano Mendola [EMAIL PROTECTED] writes:
I'm the administrator of that machine and PLCheck is failing.
Is there anything I can do to fix it ?
What version of Python have you got on that thing? It seems to be
emitting still another spelling of the encoding error message :-(
Thanks - fix committed to svn.
Regards, Dave
From: [EMAIL PROTECTED]
[mailto:[EMAIL PROTECTED] On Behalf Of Bastiaan
WakkieSent: 03 October 2005 17:04To: Andreas
PflugCc: PostgreSQL-development; pgadmin-hackers;
pgsql-admin@postgresql.orgSubject: Re: [pgadmin-hackers]
Hi,
On Mon, 3 Oct 2005, Philip Yarra wrote:
Devrim, I had some problems installing on RedHat ES3.0 with the RPMs. This
issue turned out to be that I needed the compat libs to provide the old libs
before I could install the new libs.
I found a link to
Martijn van Oosterhout Wrote:
Has it actually happened to you? PostgreSQL is pretty good
about its memory usage. Besides, seems to me it should be an
system admisitrator descision.
No, Just came across this by chance, and thought it might be a good
idea.
Perhaps as a postgresql.conf
Tom Lane Wrote:
(a) wouldn't that require root privilege? (b) how would we
determine whether we are on a system to which this applies?
(c) is it actually documented in a way that makes you think
it'll be a permanently supported feature (ie, somewhere
outside the source code)?
(a) No,
On Mon, Oct 03, 2005 at 10:36:57AM -0400, Tom Lane wrote:
Simon Riggs [EMAIL PROTECTED] writes:
The following patch implements a fairly light set of timing
statements aimed at understanding external sort performance. There
is no attempt to alter the algorithms.
What do people think about
Martijn van Oosterhout wrote:
On Mon, Oct 03, 2005 at 11:03:06PM +1000, John Hansen wrote:
Might it be worth while protecting the postmaster from an OOM Kill on
Linux by setting /proc/{pid}/oom_adj to -17 ?
(Described vaguely in mm/oom_kill.c)
Has it actually happened to you? PostgreSQL is
Michael,
Realistically, you can't do better than about 25MB/s on a
single-threaded I/O on current Linux machines,
What on earth gives you that idea? Did you drop a zero?
Nope, LOTS of testing, at OSDL, GreenPlum and Sun. For comparison, A
Big-Name Proprietary Database doesn't get much
On P, 2005-10-02 at 22:49 -0400, Greg Stark wrote:
No, I think redefining NULL is a non-starter. This whole thing only has legs
if Postgres can distinguish between a column that has never been set and a
column that has NULL.
Actually the only case where I don't see bizarre semantic
On Mon, 2005-10-03 at 10:36 -0400, Tom Lane wrote:
Simon Riggs [EMAIL PROTECTED] writes:
The following patch implements a fairly light set of timing statements
aimed at understanding external sort performance. There is no attempt to
alter the algorithms.
What do people think about
Based upon profiling of the initial stage of external sorting, it seems
that this stage is overall CPU bound, with hotspots in comparetup_*
accounting for around 50% of CPU time; lets just call that too much,
since your exact experience may vary.
Previously, I'd looked through all of the code
On P, 2005-10-02 at 23:00 -0400, Tom Lane wrote:
Greg Stark [EMAIL PROTECTED] writes:
It would be nice to be able to do:
ALTER TABLE ADD foo integer DEFAULT 1
And there's no question of what what the semantics of this are.
Sure, but you can only optimize this if the default expression
Tom,
Raising work_mem to a gig should result in about five runs, needing only
one pass, which is really going to be as good as it gets. If you could
not see any difference then I see little hope for the idea that reducing
the number of merge passes will help.
Right. It *should have*, but
On Mon, 2005-10-03 at 13:34 -0700, Josh Berkus wrote:
Michael,
Realistically, you can't do better than about 25MB/s on a
single-threaded I/O on current Linux machines,
What on earth gives you that idea? Did you drop a zero?
Nope, LOTS of testing, at OSDL, GreenPlum and Sun. For
Jeff,
Nope, LOTS of testing, at OSDL, GreenPlum and Sun. For comparison, A
Big-Name Proprietary Database doesn't get much more than that either.
I find this claim very suspicious. I get single-threaded reads in
excess of 1GB/sec with XFS and 250MB/sec with ext3.
Database reads? Or
Jeff, are those _burst_ rates from HD buffer or _sustained_ rates from
actual HD media? Rates from IO subsystem buffer or cache are
usually considerably higher than Average Sustained Transfer Rate.
Also, are you measuring _raw_ HD IO (bits straight off the platters, no
FS or other overhead) or
On Mon, Oct 03, 2005 at 01:25:00PM -0700, Jeff Davis wrote:
Martijn van Oosterhout wrote:
On Mon, Oct 03, 2005 at 11:03:06PM +1000, John Hansen wrote:
Might it be worth while protecting the postmaster from an OOM Kill on
Linux by setting /proc/{pid}/oom_adj to -17 ?
(Described vaguely in
On Mon, Oct 03, 2005 at 09:35:30PM +0100, Simon Riggs wrote:
Based upon profiling of the initial stage of external sorting, it seems
that this stage is overall CPU bound, with hotspots in comparetup_*
accounting for around 50% of CPU time; lets just call that too much,
since your exact
Jeff, Josh,
On 10/3/05 2:16 PM, Josh Berkus josh@agliodbs.com wrote:
Jeff,
Nope, LOTS of testing, at OSDL, GreenPlum and Sun. For comparison, A
Big-Name Proprietary Database doesn't get much more than that either.
I find this claim very suspicious. I get single-threaded reads in
On Mon, 2005-10-03 at 14:16 -0700, Josh Berkus wrote:
Jeff,
Nope, LOTS of testing, at OSDL, GreenPlum and Sun. For comparison, A
Big-Name Proprietary Database doesn't get much more than that either.
I find this claim very suspicious. I get single-threaded reads in
excess of
On E, 2005-10-03 at 14:16 -0700, Josh Berkus wrote:
Jeff,
Nope, LOTS of testing, at OSDL, GreenPlum and Sun. For comparison, A
Big-Name Proprietary Database doesn't get much more than that either.
I find this claim very suspicious. I get single-threaded reads in
excess of 1GB/sec
On Sun, 2005-10-02 at 21:38 +0200, Martijn van Oosterhout wrote:
Ok, I tried two optimisations:
2. By specifying: -Winline -finline-limit-1500 (only on tuplesort.c).
This causes inlineApplySortFunction() to be inlined, like the code
obviously expects it to be.
default build (baseline)
Hannu,
On 10/3/05 2:43 PM, Hannu Krosing [EMAIL PROTECTED] wrote:
Just FYI, I run a count(*) on a 15.6GB table on a lightly loaded db and
it run in 163 sec. (Dual opteron 2.6GHz, 6GB RAM, 6 x 74GB 15k disks in
RAID10, reiserfs). A little less than 100MB sec.
This confirms our findings -
Michael,
Nope, LOTS of testing, at OSDL, GreenPlum and Sun. For comparison, A
Big-Name Proprietary Database doesn't get much more than that either.
You seem to be talking about database IO, which isn't what you said.
Right, well, it was what I meant. I failed to specify, that's all.
--
Jeffrey,
I guess database reads are different, but I remain unconvinced that they
are *fundamentally* different. After all, a tab-delimited file (my sort
workload) is a kind of database.
Unfortunately, they are ... because of CPU overheads. I'm basing what's
reasonable for data writes on
On Mon, Oct 03, 2005 at 01:25:00PM -0700, Jeff Davis wrote:
It's happened to me...
Usually it's when there's some other runaway process, and the kernel
decides to kill PostgreSQL because it can't tell the difference.
I really don't like that feature in linux. Nobody has been able to
explain
Instead of ignoring the first line of a COPY FROM ... WITH CSV HEADER,
what about allowing the first line to be used as a list of field names?
This means you wouldn't have to include field order in the COPY command
if the names matched field names in the table.
--
Jim C. Nasby, Sr. Engineering
On Mon, Oct 03, 2005 at 05:19:43PM +0200, Gaetano Mendola wrote:
Tom Lane wrote:
Gaetano Mendola [EMAIL PROTECTED] writes:
I'm the administrator of that machine and PLCheck is failing.
Is there anything I can do to fix it ?
What version of Python have you got on that thing? It seems
Simon Riggs [EMAIL PROTECTED] writes:
The following patch implements a fairly light set of timing statements
aimed at understanding external sort performance. There is no attempt to
alter the algorithms.
Minor update of patch, use this version please.
Applied with revisions: I made it use
On Mon, 2005-10-03 at 18:59 -0400, Tom Lane wrote:
Simon Riggs [EMAIL PROTECTED] writes:
The following patch implements a fairly light set of timing statements
aimed at understanding external sort performance. There is no attempt to
alter the algorithms.
Minor update of patch, use this
On Mon, 2005-10-03 at 23:25 +0200, Martijn van Oosterhout wrote:
Possible problem with caching:
if you're called by the system qsort, can you assume anything about the
order of the comparisons?
That applies only to the non-external sort case, which I'm not trying to
improve with these
Let's pretend we get a 24HD HW RAID solution like that J Baker
says he has access to and set it up as a RAID 10. Assuming
it uses two 64b 133MHz PCI-X busses and has the fastest HDs
available on it, Jeff says he can hit ~1GBps of XFS FS IO rate
with that set up (12*83.3MBps= 1GBps).
Josh says
On 10/3/05, Ron Peacetree [EMAIL PROTECTED] wrote:
[snip]
Just how bad is this CPU bound condition? How powerful a CPU is
needed to attain a DB IO rate of 25MBps?
If we replace said CPU with one 2x, 10x, etc faster than that, do we
see any performance increase?
If a modest CPU can drive a
OK, change performance to single thread performance and we
still have a valid starting point for a discussion.
Ron
-Original Message-
From: Gregory Maxwell [EMAIL PROTECTED]
Sent: Oct 3, 2005 8:19 PM
To: Ron Peacetree [EMAIL PROTECTED]
Subject: Re: [HACKERS] [PERFORM] A Better External
Hi Devrim, thanks for the quick response.
We haven't discussed it before, but I think we can't put the RPM among
PGDG RPMs. The main reason is that this is not a piece of software that's
included within that release of PostgreSQL. Also, this compat RPM is not
needed if you don't have a
Didn't Alvaro write some script that we were going to use to help people
apply SQL changes against their databases?
Chris
Tom Lane wrote:
Log Message:
---
Fix procedure for updating nextval() defaults so that it actually works.
Update release dates for pending back-branch releases.
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
! (void) sprintf((char *) rp, %03o, *vp);
! (void) snprintf((char *) rp, 6, %03o, *vp);
Hardly looks like a critical fix, or even a needed one. Why bother?
No, not critical. Just something that
Just bundled up 7.3.11, 7.4.9 and 8.0.4 ... please look them over and make
sure they look okay ... will announce late tomorrow to -announce ...
Marc G. Fournier Hub.Org Networking Services (http://www.hub.org)
Email: [EMAIL PROTECTED] Yahoo!: yscrappy
Philip Yarra [EMAIL PROTECTED] writes:
Have a look at my original post: I was unable to install any of the PGDG RPMs
as they have a dependency on the contents of the compat RPM. E.g.:
[EMAIL PROTECTED] 8.x]# rpm -i postgresql-libs-8.0.3-1PGDG.i686.rpm
error: Failed dependencies:
Christopher Kings-Lynne wrote:
Didn't Alvaro write some script that we were going to use to help people
apply SQL changes against their databases?
I already wrote something up and it was in the release notes. Tom just
updated it for the new DEFAULT format after the patch.
[ I just noticed that this thread is happening on pgsql-admin, which is
completely inappropriate for discussing bugs in a beta version.
Please redirect followups to pgsql-hackers. ]
I wrote:
... The hypothesis I'm thinking about is that VACUUM is trying to do
LockBufferForCleanup() and for
Hi Tom,
On Tue, 4 Oct 2005 11:36 am, Tom Lane wrote:
I think there's no question that this represents an RPM-building error.
We haven't entirely figured out what's causing it though.
Right, gotcha. I think this may be the issue:
[EMAIL PROTECTED] 8.x]# rpm -ql postgresql-libs-8.0.3-1PGDG
Michael Fuhr [EMAIL PROTECTED] writes:
On Mon, Oct 03, 2005 at 05:19:43PM +0200, Gaetano Mendola wrote:
What version of Python have you got on that thing? It seems to be
emitting still another spelling of the encoding error message :-(
$ python -V
Python 2.2.3
The attached variant file
Hannu Krosing [EMAIL PROTECTED] writes:
Probably a different syntax would be better here, perhaps
ALTER TABLE ADD foo integer AS 1 WHEN MISSING;
or somesuch.
Uhm, if you're adding the column they're *all* missing. That's the whole
point. If you start inventing a new user-visible concept
Hannu Krosing [EMAIL PROTECTED] writes:
On P, 2005-10-02 at 23:00 -0400, Tom Lane wrote:
Here's another interesting case to think about:
ALTER TABLE ADD foo integer DEFAULT 1
...
ALTER TABLE ALTER foo SET DEFAULT 2
You'll have to pay the table-traversal cost on one
Marc G. Fournier [EMAIL PROTECTED] writes:
Just bundled up 7.3.11, 7.4.9 and 8.0.4 ... please look them over and make
sure they look okay ... will announce late tomorrow to -announce ...
Tarballs match what I have here ...
regards, tom lane
Tom Lane [EMAIL PROTECTED] writes:
Applied with revisions: I made it use the VacRUsage code so that we
could see both CPU and elapsed time, and moved the report points around
a bit. The output with trace_sort enabled looks like this:
NOTICE: begin tuple sort: nkeys = 1, workMem = 1024,
Greg Stark [EMAIL PROTECTED] writes:
I'm not actually involved in this so maybe I'm completely off base here. But
wouldn't you want to know how many tuples are being sorted and how many data
are being written in these runs in order to be able to actually make sense of
these timing
On Mon, 2005-10-03 at 23:24 -0400, Greg Stark wrote:
Hannu Krosing [EMAIL PROTECTED] writes:
On P, 2005-10-02 at 23:00 -0400, Tom Lane wrote:
Here's another interesting case to think about:
ALTER TABLE ADD foo integer DEFAULT 1
...
ALTER TABLE ALTER foo SET DEFAULT 2
On Mon, 2005-10-03 at 23:51 -0400, Rod Taylor wrote:
On Mon, 2005-10-03 at 23:24 -0400, Greg Stark wrote:
Hannu Krosing [EMAIL PROTECTED] writes:
On P, 2005-10-02 at 23:00 -0400, Tom Lane wrote:
Here's another interesting case to think about:
ALTER TABLE ADD foo
Rod Taylor [EMAIL PROTECTED] writes:
Hm. So you're saying there are only ever exactly two types of defaults. The
initial default that applies to all tuples that were created before the
column was added. And the current default that only ever applies to newly
created tuples.
That does
Simon Riggs [EMAIL PROTECTED] writes:
AFAICS the following opportunities exist, without changing any of the
theoretical algorithms or the flexibility of definable datatypes:
1. tuplesort_heap_siftup and tuplesort_heap_insert make no attempt to
cache the values of keys that have been obtained
As I understand it vacuum operates outside of the regular transaction
and if you stop it (SIGTERM, or pg_cancel_backend()) some of the work it
accomplished will be kept when it rolls back.
For large structures with a ton of dead entries (which I seem to have a
case), running vacuum takes long
68 matches
Mail list logo
