Joshua D. Drake wrote:
> Dave Page wrote:
> >
> >
> >
> >>-Original Message-
> >>From: Joshua D. Drake [mailto:[EMAIL PROTECTED]
> >>Sent: 27 April 2005 17:46
> >>To: Dave Page
> >>Cc: Josh Berkus; Joel Fradkin; PostgreSQL Perform
> >>Subject: Re: [PERFORM] Final decision
> >>
> >>
> >
Joshua D. Drake wrote:
> >>Mind you, having 2 different teams working on two different ODBC drivers is
> >>a
> >>problem for another list ...
> >
> >
> > Only two? I thought another commercial entity was also working on their
> > own ODBC driver, so there may be three of them.
>
> Well I only
Dave Page wrote:
-Original Message-
From: Joshua D. Drake [mailto:[EMAIL PROTECTED]
Sent: 27 April 2005 17:46
To: Dave Page
Cc: Josh Berkus; Joel Fradkin; PostgreSQL Perform
Subject: Re: [PERFORM] Final decision
It is? No-one told the developers...
We have mentioned it on the list.
Mind you, having 2 different teams working on two different ODBC drivers is a
problem for another list ...
Only two? I thought another commercial entity was also working on their
own ODBC driver, so there may be three of them.
Well I only know of one company actually working on ODBC actively and
On Wed, Apr 27, 2005 at 08:09:27PM -0700, Josh Berkus wrote:
> Mind you, having 2 different teams working on two different ODBC drivers is a
> problem for another list ...
Only two? I thought another commercial entity was also working on their
own ODBC driver, so there may be three of them.
--
Dave, folks,
> Err, yes. But that's not quite the same as core telling us the current
> driver is being replaced.
Sorry, I spoke off the cuff.I also was unaware that work on the current
driver had renewed. Us Core people are not omnicient, believe it or don't.
Mind you, having 2 different
Greg,
> In fact I think it's generally superior to having a layer like pgpool
> having to hand off all your database communication. Having to do an extra
> context switch to handle every database communication is crazy.
Although, one of their issues is that their database connection pooling is
p
Jeff <[EMAIL PROTECTED]> writes:
> Are you (Anjan) using real or fake connection pooling - ie pgpool versus php's
> persistent connections ? I'd strongly recommend looking at pgpool. it does
> connection pooling correctly (A set of X connections shared among the entire
> box rather than 1 per web
BTW, http://stats.distributed.net/~decibel/base.log is a test I ran;
select count(*) was ~6x faster than explain analyze select *.
On Tue, Apr 26, 2005 at 07:46:52PM -0700, Kevin Brown wrote:
> Josh Berkus wrote:
> > Jim, Kevin,
> >
> > > > Hrm... I was about to suggest that for timing just the q
Using Resin's connection pooling. We are looking into pgpool alongside
slony to separate some reporting functionality.
-anjan
-Original Message-
From: Jeff [mailto:[EMAIL PROTECTED]
Sent: Wednesday, April 27, 2005 3:29 PM
To: Greg Stark
Cc: Anjan Dave; pgsql-performance@postgresql.org
Su
Yes, HT is turned off (I haven't seen any recommendations to keep it
on).
This is when we were seeing 30 to 50% less traffic (users) than today -
we didn't want the idle connections in the pool to expire too soon
(default 30 secs, after which it goes back to pool) and reopen it
quickly, or not hav
> -Original Message-
> From: Joshua D. Drake [mailto:[EMAIL PROTECTED]
> Sent: 27 April 2005 17:46
> To: Dave Page
> Cc: Josh Berkus; Joel Fradkin; PostgreSQL Perform
> Subject: Re: [PERFORM] Final decision
>
> > It is? No-one told the developers...
>
> We have mentioned it on the lis
Joel Fradkin wrote:
...
I am guessing our app is like 75% data entry and 25% reporting, but the
reporting is taking the toll SQL wise.
This was from my insert test with 15 users.
Test type: Dynamic
Simultaneous browser connections: 15
Warm up time (secs): 0
Test duration: 00:00:03:13
Test itera
On Apr 27, 2005, at 2:29 PM, Greg Stark wrote:
"AI would seriously look at tuning those connection pools down. A lot.
If your
server processes are sitting idle over half the time I would at least
cut it
by a factor of 2.
Are you (Anjan) using real or fake connection pooling - ie pgpool
versus p
Joshua,
This article was in July 2002, so is there update to this information?
When will a new ODBC driver be available for testing? Is there a release
of the ODBC driver with better performance than 7.0.3.0200 for a 7.4.x
database?
Steve Poe
We have mentioned it on the list.
http://www.linuxde
Sorry, I didn't attach vmstat, the system does actively swap pages. Not
to the point where it crawls, but for some brief periods the console
becomes a bit unresponsive. I am taking this as a sign to prevent future
problems.
anjan
-Original Message-
From: Jeff [mailto:[EMAIL PROTECTED]
Se
Just realize, you probably *don't* want to set that in postgresql.conf.
You just want to issue an "SET enable_seqscan TO off" before issuing one
of the queries that are mis-planned.
I believe all the tested queries (90 some odd views) saw an improvement.
I will however take the time to verify this
"Anjan Dave" <[EMAIL PROTECTED]> writes:
> Some background:
>
> This is a quad XEON (yes, Dell) with 12GB of RAM, pg 7.4...pretty heavy
> on concurrent usage. With peak traffic (db allows 1000 connections, in
> line with the number of app servers and connection pools for each)
> following is fro
On Apr 27, 2005, at 1:48 PM, Anjan Dave wrote:
As you can see the system starts utilizing swap at some point, with so
many processes. Some time ago we had decided to keep the connections
from the pool open for longer
You've shown the system has used swap but not that it is swapping.
Having swap
BTW, your performance troubleshooting will continue to be hampered if you
can't share actual queries and data structure. I strongly suggest that you
make a confidentiality contract with a support provider so that you can
give them detailed (rather than general) problem reports.
I am glad to h
Hello,
I am trying to understand what I need to do for this system
to stop using swap. Maybe it’s something simple, or obvious for the
situation. I’d appreciate some thoughts/suggestions.
Some background:
This is a quad XEON (yes, Dell) with 12GB of RAM, pg 7.4…pretty
heavy on con
Joel Fradkin wrote:
I spent a great deal of time over the past week looking seriously at
Postgres and MYSQL.
Objectively I am not seeing that much of an improvement in speed with
MYSQL, and we have a huge investment in postgrs.
So I am planning on sticking with postgres fro our production database
Richard Rowell wrote:
I've ported enough of my companies database to Postgres to make
warehousing on PG a real possibility. I thought I would toss my data
migration architecture ideas out for the list to shoot apart..
1. Script on production server dumps the production database (MSSQL) to
a set o
"Dave Held" <[EMAIL PROTECTED]> writes:
> > Actually, it's more to characterize how large of a sample
> > we need. For example, if we sample 0.005 of disk pages, and
> > get an estimate, and then sample another 0.005 of disk pages
> > and get an estimate which is not even close to the first
> >
It is? No-one told the developers...
We have mentioned it on the list.
http://www.linuxdevcenter.com/pub/a/linux/2002/07/16/drake.html
Ooops ;)
http://archives.postgresql.org/pgsql-odbc/2005-03/msg00109.php
Sincerely,
Joshua D. Drake
Command Prompt, Inc.
--
Your PostgreSQL solutions company - Comm
Dave Page wrote:
-Original Message-
From: [EMAIL PROTECTED]
[mailto:[EMAIL PROTECTED] On Behalf Of
Josh Berkus
Sent: 27 April 2005 17:14
To: Joel Fradkin
Cc: PostgreSQL Perform
Subject: Re: [PERFORM] Final decision
Actually, I think the problem may be ODBC. Our ODBC driver
is not
Dave,
> > Actually, I think the problem may be ODBC. Our ODBC driver
> > is not the best
> > and is currently being re-built from scratch.
>
> It is? No-one told the developers...
>
> Regards, Dave
>
> [and yes, I know Joshua said Command Prompt are rewriting /their/
> driver]
OK. Well, let's
> -Original Message-
> From: [EMAIL PROTECTED]
> [mailto:[EMAIL PROTECTED] On Behalf Of
> Josh Berkus
> Sent: 27 April 2005 17:14
> To: Joel Fradkin
> Cc: PostgreSQL Perform
> Subject: Re: [PERFORM] Final decision
>
> Actually, I think the problem may be ODBC. Our ODBC driver
> is
Joel,
> So I am planning on sticking with postgres fro our production database
> (going live this weekend).
Glad to have you.
> I did not find any resolutions to my issues with Commandprompt.com (we only
> worked together 2.5 hours).
BTW, your performance troubleshooting will continue to be ham
I've ported enough of my companies database to Postgres to make
warehousing on PG a real possibility. I thought I would toss my data
migration architecture ideas out for the list to shoot apart..
1. Script on production server dumps the production database (MSSQL) to
a set of delimited text file
> -Original Message-
> From: Josh Berkus [mailto:[EMAIL PROTECTED]
> Sent: Wednesday, April 27, 2005 10:25 AM
> To: Andrew Dunstan
> Cc: Mischa Sandberg; pgsql-perform; pgsql-hackers@postgresql.org
> Subject: Re: [HACKERS] [PERFORM] Bad n_distinct estimation; hacks
> suggested?
>
> [...]
>
>
> I did have a question if any folks are using two servers one for
> reporting and one for data entry what system should be the beefier?
Yeah. We started putting up slaves for reporting purposes and
application specific areas using Slony replicating partial data sets to
various locations -- so
Mischa,
> >Perhaps I can save you some time (yes, I have a degree in Math). If I
> >understand correctly, you're trying extrapolate from the correlation
> >between a tiny sample and a larger sample. Introducing the tiny sample
> >into any decision can only produce a less accurate result than just
Sorry I am using Redhat AS4 and postgres
8.0.2
Joel
You didnt tell us what OS
are you using, windows?
If you want good
performance you must install unix on that machine,
---
-Original Message-From:
[EMAIL PROTECTED]
[mailto:[EMAIL PROTECTED]On Behalf Of Joel
FradkinSent: Wednesday, April 27, 2005 9:02 AMTo:
PostgreSQL PerformSubject: [PERFORM] Final
decision
I spent a great deal of time over
the past week looking seriously at Post
I spent a great deal of time over the past week looking
seriously at Postgres and MYSQL.
Objectively I am not seeing that much of an improvement in
speed with MYSQL, and we have a huge investment in postgrs.
So I am planning on sticking with postgres fro our
production database (going liv
Hi,
On Sun, Mar 20, 2005 at 06:01:49PM -0500, Tom Lane wrote:
> Global indexes would seriously reduce the performance of both vacuum and
> cluster for a single partition, and if you want seq scans you don't need
> an index for that at all. So the above doesn't strike me as a strong
> argument for
On Tue, 2005-04-26 at 15:00 -0700, Gurmeet Manku wrote:
> 2. In a single scan, it is possible to estimate n_distinct by using
> a very simple algorithm:
>
> "Distinct sampling for highly-accurate answers to distinct value
> queries and event reports" by Gibbons, VLDB 2001.
>
> http://ww
38 matches
Mail list logo
