> It's not an easy decision. Linux isn't wrong. Solaris isn't wrong.
> Most people never hit these problems, and the people that do, are
> just as likely to hit one problem, or the other. The grass is always
> greener on the side of the fence that isn't hurting me right now,
> and all that.
>
> Ch
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 enou
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 obta
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.
>
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:
> > > >
> > > >
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
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 measure
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 = 10
"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
--
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-tra
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 c
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
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
[sni
[ 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
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.
--
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:
>
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 ICQ:
-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 somethin
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.
Mo
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 sof
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 Ex
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
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 th
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 sugges
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 pa
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 i
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 thin
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 Con
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
> exp
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
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.
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
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 (baseli
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
> > exce
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
> > ex
Jeff, Josh,
On 10/3/05 2:16 PM, "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
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 expe
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 ?
> >>(Describe
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 _c
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?
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 e
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
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*, bu
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 wit
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 ab
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 cons
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 mu
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? Pos
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 t
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)
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 sett
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
http://developer.PostgreSQL.org/~devrim/co
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] pgAd
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 me
> -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
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
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'
"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
"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,
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 :-(
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 t
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
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 us
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: i
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 -000
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
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/
--
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
68 matches
Mail list logo
