Hi,
I am trying to optimize my Debian Sarge AMD64 PostgreSQL 8.0
installation, based on the recommendations from the Annotated
POSTGRESQL.CONF Guide for
PostgreSQL (http://www.powerpostgresql.com/Downloads/annotated_conf_80.html).
To see the result of the recommendations I use pgbench from
Hi Gavin,
Thanks for answering.
On Tue, 2005-11-01 at 20:16 +1100, Gavin Sherry wrote:
On Tue, 1 Nov 2005, Joost Kraaijeveld wrote:
1. Is there a repository somewhere that shows results, using and
documenting different kinds of hard- and software setups so that I can
compare my results
On Mon, 2005-10-31 at 16:18 -0500, Tom Lane wrote:
Kelly Burkhart [EMAIL PROTECTED] writes:
Ha! So I'm creating an index 98% full of nulls! Looks like this is
easily fixed with partial indexes.
Still, though, it's not immediately clear why you'd be seeing a severe
dropoff in insert
Kelly Burkhart [EMAIL PROTECTED] writes:
Tom, I'd be happy to profile the backend at several points in the run if
you think that would be helpful. What compiler flags should I use?
Add -g -pg and leave the rest alone. Also, if you're on Linux note that
you need -DLINUX_PROFILE.
It may be
We are going live with a application in a few months that is a complete
rewrite of an existing application. We are moving from an existing
proprietary database to Postgresql. We are looking for some
insight/suggestions as to how folks test Postgresql in such a situation.
We really want to
On Mon, 31 Oct 2005 17:16:46 -0600
PostgreSQL [EMAIL PROTECTED] wrote:
We're running 8.1beta3 on one server and are having ridiculous
performance issues. This is a 2 cpu Opteron box and both processors
are staying at 98 or 99% utilization processing not-that-complex
queries. Prior to the
I'm surprised that no one seems to have yet suggested the following
simple experiment:
Increase the RAM 4GB - 8GB, tune for best performance, and
repeat your 100M row insert experiment.
Does overall insert performance change? Does the performance
drop foo rows in still occur? Does it occur in
On 1/11/05 2:50 pm, Jon Brisbin [EMAIL PROTECTED] wrote:
On Mon, 31 Oct 2005 17:16:46 -0600
PostgreSQL [EMAIL PROTECTED] wrote:
We're running 8.1beta3 on one server and are having ridiculous
performance issues. This is a 2 cpu Opteron box and both processors
are staying at 98 or 99%
Jon Brisbin [EMAIL PROTECTED] writes:
I have a stock FreeBSD 5.4 box that I put 8.1 on last night. I ran
pgbench against it and my tps dropped from ~300tps in 8.0.3 to 20tps
in 8.1. That's right. 20. No changes in any system configuration.
You sure about that last? These numbers are kind of
hello performance minded administrators:
We have recently converted a number of routines that walk a bill of
materials (which is a nested structure) from the application side to the
server side via recursive plpgsql functions. The performance is
absolutely fantastic but I have to maintain a
Geoffrey wrote:
We are going live with a application in a few months that is a
complete
rewrite of an existing application. We are moving from an existing
proprietary database to Postgresql. We are looking for some
insight/suggestions as to how folks test Postgresql in such a
situation.
Merlin Moncure [EMAIL PROTECTED] writes:
A simplified idealized version of what I would like to do is
begin
select (callback_routine)(record_type)
end;
from within a plpgsql function. I am borrowing the C syntax for a
function pointer here.
Well, there's no function
Would you be willing to write up an example of this? We often get asked
about support for WITH, so I bet there's other people who would be very
interested in what you've got.
On Tue, Nov 01, 2005 at 05:13:48PM -0500, Merlin Moncure wrote:
The body of callit() need be little more than
Merlin Moncure wrote:
Geoffrey wrote:
We are going live with a application in a few months that is a complete
rewrite of an existing application. We are moving from an existing
proprietary database to Postgresql. We are looking for some
insight/suggestions as to how folks test Postgresql in
I have a client that is testing an internal data platform, and they
were happy with PostgreSQL until they tried to join views - at that
time they discovered PostgreSQL was not using the indexes, and the
queries took 24 hours to execute as a result.
Is this a known issue, or is this possibly a
On Tue, Nov 01, 2005 at 06:16:59PM -0500, Mitch Pirtle wrote:
I have a client that is testing an internal data platform, and they
were happy with PostgreSQL until they tried to join views - at that
time they discovered PostgreSQL was not using the indexes, and the
queries took 24 hours to
Mitch Pirtle [EMAIL PROTECTED] writes:
I have a client that is testing an internal data platform, and they
were happy with PostgreSQL until they tried to join views - at that
time they discovered PostgreSQL was not using the indexes, and the
queries took 24 hours to execute as a result.
On Tue, Nov 01, 2005 at 06:16:59PM -0500, Mitch Pirtle wrote:
I have a client that is testing an internal data platform, and they
were happy with PostgreSQL until they tried to join views - at that
time they discovered PostgreSQL was not using the indexes, and the
queries took 24 hours to
Tom Lane [EMAIL PROTECTED] wrote
No, that's completely irrelevant to his problem. The reason we can't do
this is that the transformation from x const to a range check on x
is a plan-time transformation; there's no mechanism in place to do it
at runtime. This is not easy to fix, because
Qingqing Zhou [EMAIL PROTECTED] writes:
Tom Lane [EMAIL PROTECTED] wrote
No, that's completely irrelevant to his problem. The reason we can't do
this is that the transformation from x const to a range check on x
is a plan-time transformation; there's no mechanism in place to do it
at
20 matches
Mail list logo
