> Hmmm ... [squints] ... it's not supposed to do that ...
The attached patch seems to make it better.
regards, tom lane
Index: src/backend/optimizer/path/costsize.c
===
RCS file: /cvsroot/pgsql-server/src/ba
Tom Lane wrote:
Hmmm ... [squints] ... it's not supposed to do that ...
The attached patch seems to make it better.
The patch definitely makes things more consistent...unfortunately it is
more
consistent toward the slower execution times. Of course I am looking at
this
simply from a st
On Wed, 3 Dec 2003 [EMAIL PROTECTED] wrote:
> Dear all
>
> We would be recommending to our ct. on the use of Postgresql db as compared
> to MS SQL Server. We are targetting to use Redhat Linux ES v2.1, Postgresql
> v7.3.4 and Postgresql ODBC 07.03.0100.
>
> We would like to know the minimum spec
"scott.marlowe" <[EMAIL PROTECTED]> writes:
> > 3) Estimated number of transactions to be written into the Postgresql db is
> > around 15000 records per day.
> >
> > The growth rate in terms of number of connections is around 10% per year
> > and the data retention is kept on average at least fo
Jared Carr <[EMAIL PROTECTED]> writes:
> The patch definitely makes things more consistent...unfortunately it is more
> consistent toward the slower execution times. Of course I am looking at this
> simply from a straight performance standpoint and not a viewpoint of what
> *should* be happening.
1) We will be running 2 x Postgresql db in the machine.
2) Total number of connections to be around 100. The connections from the
clients machines will be in ODBC and socket connections.
3) Estimated number of transactions to be written into the Postgresql db is
around 15000 records per day.
Assu
Thanks to Greg Stark, Tom Lane and Stephan Szabo for their advice on
rewriting my query... the revised query plan claims it should only take
about half the time my original query did.
Now for a somewhat different question: How might I improve my DB
performance by adjusting the various paramet
> shared_buffers = 128# min max_connections*2 or 16, 8KB each
Try 1500.
> sort_mem = 65535# min 64, size in KB
I'd pull this in. You only have 640MB ram, which means about 8 large
sorts to swap.
How about 16000?
> fsync = false
I presume you understand the risks involved with
To all,
We are building a data warehouse composed of essentially click stream
data. The DB is growing fairly quickly as to be expected, currently at
90GB for one months data. The idea is to keep 6 months detailed data on
line and then start aggregating older data to summary tables. We have 2
I should also add that we have already done a ton of tuning based on the
archives of this list so we are not starting from scratch here.
Thanks.
--sean
Sean Shanny wrote:
To all,
We are building a data warehouse composed of essentially click stream
data. The DB is growing fairly quickly as
Sean
Second and more radical, has anyone run postgreSQL on the new Apple
G5 with an XRaid system? This seems like a great value combination.
Fast CPU, wide bus, Fibre Channel IO, 2.5TB all for ~17k.
I keep see references to terabyte postgreSQL installations, I was
wondering if anyone on thi
Just wondering if anyone has done any testing on the amount of overhead
for insert you might gain by adding a serial column to a table. I'm
thinking of adding a few to some tables that get an average of 30 - 40
inserts per second, sometimes bursting over 100 inserts per second and
wondering if the
> We are running into issues with IO saturation obviously. Since this
> thing is only going to get bigger we are looking for some advice on
> how to accommodate DB's of this size.
> Second and more radical, has anyone run
> postgreSQL on the new Apple G5 with an XRaid system? This seems like
Tom Lane wrote:
> Greg Stark <[EMAIL PROTECTED]> writes:
> > Tom Lane <[EMAIL PROTECTED]> writes:
> >> Define "no longer works well".
>
> > Well it seems to completely bar the use of a straight merge join between two
> > index scans:
>
> Hmmm ... [squints] ... it's not supposed to do that ... [di
Greg Stark wrote:
Jared Carr <[EMAIL PROTECTED]> writes:
The patch definitely makes things more consistent...unfortunately it is more
consistent toward the slower execution times. Of course I am looking at this
simply from a straight performance standpoint and not a viewpoint of what
*should*
Tom Lane wrote:
Hmmm ... [squints] ... it's not supposed to do that ...
The attached patch seems to make it better.
I guess is too late for 7.3.5.
:-(
Any chance for 7.4.1 ?
Regards
Gaetano Mendola
---(end of broadcast)---
TIP 3: if posting/re
Sean Shanny wrote:
We are currently running on a Dell 2650 with 2 Xeon 2.8 processors in
hyper-threading mode, 4GB of ram, and 5 SCSI drives in a RAID 0, Adaptec
PERC3/Di, configuration. I believe they are 10k drives. Files system
is EXT3. We are running RH9 Linux kernel 2.4.20-20.9SMP with
Gaetano,
I don't believe we have ever run the system without it turned on.
Another switch to fiddle with. :-)
--sean
Gaetano Mendola wrote:
Sean Shanny wrote:
We are currently running on a Dell 2650 with 2 Xeon 2.8 processors in
hyper-threading mode, 4GB of ram, and 5 SCSI drives in a RAID
Dear all
Sorry for my mistake on the 15000 recs per day.
In fact, this server is planned as a OLTP database server for a retailer.
Our intention is either to setup 1 or 2 Postgresql db in the server.
The proper sizing info for the 1st Postgresql db should be:
No. of item master : 200,000
(Thi
On Tue, 2003-12-02 at 15:37, Vivek Khera wrote:
> Now I'm trying to implement pg_autovacuum. It seems to work ok, but
> after about an hour or so, it does nothing. The process still is
> running, but nothing is sent to the log file.
>
> I'm running the daemon as distributed with PG 7.4 release a
20 matches
Mail list logo
