Jim C. Nasby wrote:
On Mon, Jan 31, 2005 at 09:41:32PM +0100, Cosimo wrote:
>2) The goal is to make the db handle 100 tps (something like
> 100 users). What kind of server and storage should I provide?
You might look at Opteron's, which theoretically have a higher data
bandwidth. If you're doing
Tom Lane wrote:
Cosimo writes:
1) What kind of performance gain can I expect switching from
7.1 to 7.4 (or 8.0)? Obviously I'm doing my own testing,
but I'm not very impressed by 8.0 speed, may be I'm doing
testing on a low end server...
Most people report a noticeable speedup in each new
On Tue, Feb 01, 2005 at 12:06:27AM -0500, Tom Lane wrote:
> "Jim C. Nasby" <[EMAIL PROTECTED]> writes:
> > On Mon, Jan 31, 2005 at 03:26:12PM -0500, Tom Lane wrote:
> >> Preferably a whole lot of queries. All the measurement techniques I can
> >> think of are going to have a great deal of noise, s
"Trevor Ball" <[EMAIL PROTECTED]> writes:
> ... it doesn't
> seem reasonable to me that an index would slow an insert more than
> 50-fold, regardless of hardware or the nature of the index.
Seems pretty slow to me too. Can you provide a self-contained test
case?
One possibility is that depending
"Jim C. Nasby" <[EMAIL PROTECTED]> writes:
> On Mon, Jan 31, 2005 at 03:26:12PM -0500, Tom Lane wrote:
>> Preferably a whole lot of queries. All the measurement techniques I can
>> think of are going to have a great deal of noise, so you shouldn't
>> twiddle these cost settings based on just a few
On Mon, Jan 31, 2005 at 09:41:32PM +0100, Cosimo Streppone wrote:
> 2) The goal is to make the db handle 100 tps (something like
>100 users). What kind of server and storage should I provide?
>
>The actual servers our application runs on normally have
>2 Intel Xeon processors, 2-4 Gb R
On Mon, Jan 31, 2005 at 03:26:12PM -0500, Tom Lane wrote:
> Josh Berkus writes:
> >> I would like something that really measures values like random_page_cost
> >> or cpu_tuple_cost that are hardware dependent.
> >>
> >> I assume such thing does not exist?
>
> > Nope. You gotta whip out your cal
Hello my friends,
I'd like to know (based on your experience and
technical details) which OS is recommended for running PostgreSQL keeping in
mind 3 indicators:
1 - Performance (SO, Network and IO)
2 - SO Stability
3 - File System Integrity
Comparisons between Slackware, Gento
Title: Index Slowing Insert >50x
I have a data collector function in a PostGreSQL 7.4 DB running on Linux that inserts approximately 1 records into a table every fifteen minutes. The table has two macaddr columns, one varchar(50) column, two timestamptz columns, five interval columns, one
Cosimo Streppone <[EMAIL PROTECTED]> writes:
> 1) What kind of performance gain can I expect switching from
> 7.1 to 7.4 (or 8.0)? Obviously I'm doing my own testing,
> but I'm not very impressed by 8.0 speed, may be I'm doing
> testing on a low end server...
Most people report a notic
Hi all,
I've been following this list for nearly a year now.
I've always managed to get PostgreSQL 7.1.x right for the job,
which in my case is a large and complex oltp system,
run under Pg for 6 years now.
We were already planning the switch from 7.1 to 7.4 (or even 8.0).
The last project we're fa
Josh Berkus writes:
>> I would like something that really measures values like random_page_cost
>> or cpu_tuple_cost that are hardware dependent.
>>
>> I assume such thing does not exist?
> Nope. You gotta whip out your calculator and run some queries.
Preferably a whole lot of queries. All t
Markus,
> As far as I examined, those views only count several things like fetched
> rows and pages, and cache hits.
>
> I would like something that really measures values like random_page_cost
> or cpu_tuple_cost that are hardware dependent.
>
> I assume such thing does not exist?
Nope. You got
Tom,
Thank you! I will have the client try that. What
about the event_tbl_evt_id_key index question. Could
that also be causing me difficulties? Should I
periodically reindex it?
thanks,
Bill
--- Tom Lane <[EMAIL PROTECTED]> wrote:
> Bill Chandler <[EMAIL PROTECTED]> writes:
> > Update pr
Do I understand correctly, however, that when you
create a unique SERIAL column an index is
automatically created on that column? If so, does
that sound like a possible culprit? We are not doing
any reindexing on that index at all. Could it be
suffering from index bloat? Do we need to
periodic
Bill Chandler <[EMAIL PROTECTED]> writes:
> Update processes run continually throughout the day in
> which rows are inserted but none deleted.
What about row updates?
> Even seemingly simple commands are taking forever.
> For example:
> select evt_id from event_tbl where evt_id=1;
> takes over a
Hello,
Client is seeing continual performance degradation on
updates and queries from a large database. Any help
appreciated.
Client is using PostgreSQL 7.4.2 on Sparcv9 650MHZ
cpu, 2GB Ram, running Solaris.
We have the following tables:
EVENT_TBL
evt_id bigserial, unique
d1 n
> Tell me if I am wrong but it sounds to me like like
> an endless problem
Agreed. Such it is with caching. After doing some informal
benchmarking with 8.0 under Solaris, I am convinced that our major choke
point is WAL synchronization, at least for applications with a high
commit rate.
W
Le Vendredi 21 Janvier 2005 19:18, Marty Scholes a écrit :
> The indexes can be put on a RAM disk tablespace and that's the end of
> index problems -- just make sure you have enough memory available. Also
> make sure that the machine can restart correctly after a crash: the
> tablespace is dropped
Manfred,
Yeah, that was a typo. It should have been ASet.Value IS NULL.
I have considered storing the setting names by key, since I do have a
separate table with the names and a key as you suggest, but since my
application is only ~75% finished, it's still pretty important to have
Hi, Cristopher,
Christopher Kings-Lynne schrieb:
>> Are there any tools that help with postgres/postgis performance tuning?
>>
>> So they measure the acutal tuple costs and cpu power, or suggest optimal
>> values for the index sample counts?
>
> Have you turned on the stat_* settings in postgresql
fsync on.
Alex Turner
NetEconomist
On Fri, 28 Jan 2005 11:19:44 -0500, Merlin Moncure
<[EMAIL PROTECTED]> wrote:
> > With the right configuration you can get very serious throughput. The
> > new system is processing over 2500 insert transactions per second. We
> > don't need more RAM with this
Thanks joshua
i tried running vacuum command,
vacuum database as well as vacuum
but even after that querying the database , the memory shoots up
as i mentioned in the previous mail and never comes down.
Also the old pids of connections established remains even after the
connection is close
Thanks joshua
i tried running vacuum command,
vacuum database as well as vacuum
but even after that querying the database , the memory shoots up
as i mentioned in the previous mail and never comes down.
Also the old pids of connections established remains even after the
connection is closed
On Wed, 26 Jan 2005 07:16:25 -0800, "Peter Darley"
<[EMAIL PROTECTED]> wrote:
>SELECT User_ID
>FROM Assignments A NATURAL LEFT JOIN (SELECT * FROM Assignment_Settings
>WHERE Setting='Status') ASet
>WHERE A.User_ID IS NOT NULL
> AND ASet.Assignment_ID IS NULL
>GROUP BY User_ID;
"ASet.Assignme
25 matches
Mail list logo
