Simon Riggs napsal(a):
Improved monitoring and performance tuning (Tom, Bruce, Greg, Larry)
Overhead of statistics collection has been considerably reduced and new
statistics and system information is available. Better query logging
improves diagnostics and especially performance
Peter Eisentraut wrote:
I notice that when I run 'make check' on a
statically linked HEAD, it fails during
'createlang' with
Because createlang relies on *dynamic* loading.
So that is working as designed.
I interpret that as 'static builds for the database
server are not supported'. Ok by
On Wed, Sep 20, 2006 at 10:56:08AM -0700, Mark Dilger wrote:
If the system chooses cast chains based on a breadth-first search, then the
existing int2 - int8 cast would be chosen over an int2 - int4 - int8
chain, or an int2 - int3 - int4 - int8 chain, or in fact any chain at
all, because
On Wed, 2006-09-20 at 23:22 -0400, Bruce Momjian wrote:
Usually the major items just jump out of the release list. In this
case, nothing really jumped out, and I felt if I listed sereral, it was
going to look weak because they were not big things, so I figured I
would just go with the broad
True, but running several dozen instances on a single machine will
require a lot more memory (or, conversely, each individual database gets
a lot less memory to use).
Of course, this is all hand-waving right now... it'd be interesting to
see which approach was actually better.
I'm running
Tom Lane wrote:
Heikki Linnakangas [EMAIL PROTECTED] writes:
A big question is, do we need to implement spilling to disk?
My thought is no, at least not in the first cut ... this is something
that can be added later if it proves critical, and right at the moment
my guess is that it
Another question is, what should cmin and cmax system columns return? If
we overlay cmin and cmax, cmin and cmax on-disk will always be the same
value. And with phantom cids, it wouldn't be meaningful outside the
inserting/deleting transaction.
The options that I can think of are:
1. Only
On Wed, 2006-09-20 at 20:43 -0300, Tom Lane wrote:
Log Message:
---
Add documentation for new in-core advisory lock functions. Merlin Moncure
Modified Files:
--
pgsql/doc/src/sgml:
func.sgml (r1.338 - r1.339)
Heikki Linnakangas [EMAIL PROTECTED] writes:
We could also limit the size of the hash table, which takes up most of
the memory, and only keep the latest phantom cids there. Presumably, if
current command id is 1000, you're not likely to set cmax to 500 on any
tuple in that transaction
Albe Laurenz [EMAIL PROTECTED] writes:
Peter Eisentraut wrote:
Because createlang relies on *dynamic* loading.
So that is working as designed.
I interpret that as 'static builds for the database
server are not supported'. Ok by me.
Well, we're not supporting dynamically linked objects in a
I am aware that more recent versions 8.x have fixed this problem, I
checked the 7.4 release notes but can't see if any of the fixes made
it into 7.4.
Did they ?
Dave
---(end of broadcast)---
TIP 6: explain analyze is your friend
Bruce Momjian [EMAIL PROTECTED] writes:
Doesn't creating many temp tables in a transaction do the same thing?
True, but it's a tad harder/less likely that you'd accidentally cause
a problem that way.
I'm not sure if I'm crying wolf or whether there's a serious issue.
Certainly, if you have
Tom Lane wrote:
It's at least theoretically possible that you could link selected PL
objects into a static backend build, but no one is particularly
interested in expending effort on it. There don't seem to be any
platforms anymore on which --disable-shared is actually important.
(Should we
Le jeudi 21 septembre 2006 01:52, Tom Lane a écrit :
Or we could try to do something about limiting the number of such locks
that can be granted, but that seems nontrivial to tackle at such a late
stage of the devel cycle.
Thoughts?
What about reserving some amount of shared_buffers out of
Heikki Linnakangas [EMAIL PROTECTED] writes:
Another question is, what should cmin and cmax system columns return?
If we're going to fool with these, I'd like to renew the suggestion I
made awhile back that none of the system columns should have explicit
entries in pg_attribute, but rather their
Am Donnerstag, 21. September 2006 16:02 schrieb Tom Lane:
There don't seem to be any
platforms anymore on which --disable-shared is actually important.
(Should we just get rid of it?)
IIRC, I added it in the past to test for static-only platforms like QNX. I
don't know if we plan to support
* Tom Lane ([EMAIL PROTECTED]) wrote:
An admin who is concerned about this can revoke public access on the
functions for himself ... but should that be the default out-of-the-box
configuration? I feel more comfortable with saying you have to turn
on this potentially-dangerous feature than
Josh Berkus wrote:
Bruce,
What happened to PL/pgSQL debugging? Did it die?
The debuggers is going to be on pgfoundry, if it isn't there already.
The idea is that it would be loadable for 8.2, work out all the bugs,
and perhaps included in 8.3.
--
Bruce Momjian [EMAIL PROTECTED]
OK, I will work it.
---
Simon Riggs wrote:
On Wed, 2006-09-20 at 23:22 -0400, Bruce Momjian wrote:
Usually the major items just jump out of the release list. In this
case, nothing really jumped out, and I felt if I
-Original Message-
From: [EMAIL PROTECTED]
[mailto:[EMAIL PROTECTED] On Behalf Of Bruce Momjian
Sent: 21 September 2006 16:25
To: Josh Berkus
Cc: pgsql-hackers@postgresql.org; Simon Riggs
Subject: Re: [HACKERS] Release Notes: Major Changes in 8.2
Josh Berkus wrote:
Bruce,
Simon Riggs [EMAIL PROTECTED] writes:
The release notes don't mention that the advisory locks feature has been
added either.
I think Bruce only has the notes synced up to about a week ago ...
regards, tom lane
---(end of
Simon Riggs wrote:
On Wed, 2006-09-20 at 20:43 -0300, Tom Lane wrote:
Log Message:
---
Add documentation for new in-core advisory lock functions. Merlin Moncure
Modified Files:
--
pgsql/doc/src/sgml:
func.sgml (r1.338 - r1.339)
Jeremy Drake [EMAIL PROTECTED] writes:
I put together a patch which adds a regression test for large objects,
hopefully attached to this message. I would like some critique of it, to
see if I have gone about it the right way. Also I would be happy to hear
any additional tests which should be
Martijn van Oosterhout wrote:
On Wed, Sep 20, 2006 at 10:56:08AM -0700, Mark Dilger wrote:
If the system chooses cast chains based on a breadth-first search, then the
existing int2 - int8 cast would be chosen over an int2 - int4 - int8
chain, or an int2 - int3 - int4 - int8 chain, or in fact
We've seen reports occasionally of how the system reports that
max_fsm_pages needs to be increased to at least X, and then when the DBA
does so, it complains that some larger amount is needed --- one recent
report is here:
http://archives.postgresql.org/pgsql-admin/2006-06/msg00176.php
I finally
Bruce, All:
The debuggers is going to be on pgfoundry, if it isn't there already.
The idea is that it would be loadable for 8.2, work out all the bugs,
and perhaps included in 8.3.
So, should I take this off the press list for 8.2 and save it for 8.3,
when the feature will be actually
Hi, Dave,
Dave Cramer wrote:
I am aware that more recent versions 8.x have fixed this problem, I
checked the 7.4 release notes but can't see if any of the fixes made it
into 7.4.
Usually, only critical data loss and security fixes are put into the
minor updates (e. G. 7.4.0 to 7.4.13). So,
Hi, Tom,
Tom Lane wrote:
I think it's reasonable for vacuumlazy.c to track at most MaxFSMPages
pages as it's doing now --- but it should keep a separate count of the
total number of pages with at least threshold amount of free space, and
pass that as a separate argument to
Tom Lane wrote:
I think it's reasonable for vacuumlazy.c to track at most MaxFSMPages
pages as it's doing now --- but it should keep a separate count of the
total number of pages with at least threshold amount of free space, and
pass that as a separate argument to RecordRelationFreeSpace. This
On Thu, Sep 21, 2006 at 11:24:53AM -0400, Bruce Momjian wrote:
Josh Berkus wrote:
Bruce,
What happened to PL/pgSQL debugging? Did it die?
The debuggers is going to be on pgfoundry, if it isn't there already.
The idea is that it would be loadable for 8.2, work out all the bugs,
and
Tom Lane wrote:
In fact, maybe vacuum should just throw a WARNING when it
finds a single rel with more than MaxFSMPages pages with useful free
space?
I fully agree with this. This (in particular, how many useful free
pages a rel has) is information a good DBA can make very good use of,
and is
On 9/20/06, Josh Berkus josh@agliodbs.com wrote:
Supposedly someone from EnterpriseDB is working on this as well;
where are you?
Josh,
We're currently working on the design docs and a beta. Denis, Faiz,
and/or Ahsan will post here when it's posted. You should expect some
activity in this
Jonah,
We're currently working on the design docs and a beta. Denis, Faiz,
and/or Ahsan will post here when it's posted. You should expect some
activity in this area in the next two weeks or so.
So, are you saying that you already have code?
If not, care to open up the process? We have
On 9/21/06, Josh Berkus josh@agliodbs.com wrote:
So, are you saying that you already have code?
Yes.
If not, care to open up the process? We have others interested in
contributing.
We'll be opening it in the next few weeks. A large majority of it is
working but we want to solidify the
Tom Lane wrote:
Well, we're not supporting dynamically linked objects in a static build ;-)
It's at least theoretically possible that you could link selected PL
objects into a static backend build, but no one is particularly
interested in expending effort on it. There don't seem to be any
Josh Berkus wrote:
Bruce, All:
The debuggers is going to be on pgfoundry, if it isn't there already.
The idea is that it would be loadable for 8.2, work out all the bugs,
and perhaps included in 8.3.
So, should I take this off the press list for 8.2 and save it for 8.3,
when the
[EMAIL PROTECTED] (Bruce Momjian) writes:
Josh Berkus wrote:
Bruce,
What happened to PL/pgSQL debugging? Did it die?
The debuggers is going to be on pgfoundry, if it isn't there already.
The idea is that it would be loadable for 8.2, work out all the bugs,
and perhaps included in 8.3.
Simon Riggs wrote:
SQL:2003 Analytical functions (Sergey, Tom, Neil)
All statistical aggregate functions defined by SQL:2003 are now
supported and user-defined aggregates now can take multiple columns as
inputs.
Could this be a good starting point for SQL:2003 Window functions as
Markus Schaber wrote:
Hi, Dave,
Dave Cramer wrote:
I am aware that more recent versions 8.x have fixed this problem, I
checked the 7.4 release notes but can't see if any of the fixes made it
into 7.4.
Usually, only critical data loss and security fixes are put into the
minor updates
Jonah H. Harris [EMAIL PROTECTED] writes:
On 9/21/06, Josh Berkus josh@agliodbs.com wrote:
If not, care to open up the process? We have others interested in
contributing.
We'll be opening it in the next few weeks. A large majority of it is
working but we want to solidify the design and
Jonah H. Harris wrote:
On 9/21/06, Josh Berkus josh@agliodbs.com wrote:
So, are you saying that you already have code?
Yes.
If not, care to open up the process? We have others interested in
contributing.
We'll be opening it in the next few weeks. A large majority of it is
working
Tom Lane wrote:
Bruce Momjian [EMAIL PROTECTED] writes:
Doesn't creating many temp tables in a transaction do the same thing?
True, but it's a tad harder/less likely that you'd accidentally cause
a problem that way.
Then why not use a GUC (that only an administrator can set) to control
the
On Thu, 21 Sep 2006, Tom Lane wrote:
We've seen reports occasionally of how the system reports that
max_fsm_pages needs to be increased to at least X, and then when the DBA
does so, it complains that some larger amount is needed --- one recent
report is here:
I created a major features list for 8.2 and put it into CVS. Instead of
going into detail (meaning the item would not appear in the Changes
section below, I just highlighted some of the big stuff, and was
purposely vague about the details, so people just have an overview of
what is below.
Let
On 9/21/06, Tom Lane [EMAIL PROTECTED] wrote:
I see more and more people falling into the trap of doing a lot of work
*before* showing their ideas to the community. This is an excellent
plan if what you are hoping to accomplish is to waste a lot of work.
Otherwise, you'll do a lot better to get
On 9/21/06, Alvaro Herrera [EMAIL PROTECTED] wrote:
You know, if I could post the Mammoth Replicator code for comment,
I'd do it as soon as possible, design flaws and coding bugs included.
It's easy to say something on the contrary when you know you can't
back it up to begin with.
Before
Jonah H. Harris wrote:
On 9/21/06, Tom Lane [EMAIL PROTECTED] wrote:
I see more and more people falling into the trap of doing a lot of work
*before* showing their ideas to the community. This is an excellent
plan if what you are hoping to accomplish is to waste a lot of work.
Otherwise,
Jonah,
I don't think I've seen anyone actually propose a design and state
they were going to work on it (at least until 8.3)... so it's funny
that I'm trying to follow the new, keep the community informed
policy and yet everyone is still not happy enough.
Ooops, didn't mean to start a
On 9/21/06, Josh Berkus josh@agliodbs.com wrote:
Ooops, didn't mean to start a which-hunt.
Not you're fault :)
So I think the thing to decide is whether this is EDB freeware or a real
community OSS effort. I think that we'll be happy to have either, but
right now it's in some grey area.
We would help if we do it in an open pgfoundry project.
Bizgres?
- Luke
Msg is shrt cuz m on ma treo
-Original Message-
From: Josh Berkus [mailto:[EMAIL PROTECTED]
Sent: Thursday, September 21, 2006 11:08 PM Eastern Standard Time
To: Jonah H. Harris
Cc:
Jonah,
We certainly want it to be a community effort, we're just cleaning up
the design right now. The code itself will be posted as-is for anyone
to break, patch, and enhance.
Even if the design is the only thing the community latches onto,
improves, and drives into a new working pg_upgrade,
On 9/21/06, Josh Berkus josh@agliodbs.com wrote:
OK ... can we re-name the project, please, though? It's going to be
hard for employees of other companies to contribute to the EnterpriseDB
Migrator. Maybe PGMigrator with EnterpriseDB leading off the
discription?
I can't personally make
Jonah H. Harris [EMAIL PROTECTED] writes:
In short, our design is based on many of the pg_upgrade concepts but
rewritten in C... if you have any blatant faults in pg_upgrade, that's
the best place to start discussion.
Well, actually, there's a reason why pg_upgrade isn't in the CVS tree
Dropping -general.
On Sep 14, 2006, at 5:33 PM, Steve Crawford wrote:
I would like the ability to absolutely set parameters/settings in psql
so that our psql scripts could generate predictable output absent a
known or controllable initial state. Original discussion at bottom of
message.
One
54 matches
Mail list logo
