Hello,
We have the next scenario:
Linux box with postgresql 7.2.1-1 (client)
Windows XP with postgresql 8.1.1 (server)
Windows XP with postgresql 8.1.1 (client)
All connected in 10Mb LAN
In server box, we have a table with 65000 rows and usign psql we have
these results:
Linux box with
Josep Maria Pinyol Fontseca wrote:
Linux box with psql version 7.2.1 versus Windows XP server:
select * from table; - 7 seconds aprox. to obtain a results.
Network utilization: 100%
Windows XP client box with psql version 8.1.1 versus Windows XP server:
select * from table; - 60 seconds
I hope this isn't too far off topic for this list. Postgres is
the main application that I'm looking to accomodate. Anything
else I can do with whatever solution we find is just gravy...
You've given me a lot to go on... Now I'm going to have to do some
research as to real-world RAID
Jim C. Nasby wrote:
How much space does that equate to?
Have you optimized the queries?
Items that generally have the biggest impact on performance in
decreasing order:
1. System architecture
2. Database design
3. (for long-running/problem queries) Query plans
4. Disk I/O
5. Memory
6. CPU
Charles,
On 12/20/05 9:58 PM, Charles Sprickman [EMAIL PROTECTED] wrote:
You've given me a lot to go on... Now I'm going to have to do some
research as to real-world RAID controller performance. It's vexing (to
say the least) that most vendors don't supply any raw throughput or TPS
stats
On Sun, Dec 18, 2005 at 01:10:21AM -, Ben Trewern wrote:
I know I should be writing these in C but that's a bit beyond me. I was
going to try PL/Python or PL/Perl or even PL/Ruby. Has anyone any idea
which language is fastest, or is the data access going to swamp the overhead
of small
Try to execute your query (in psql) with prefixing by EXPLAIN ANALYZE and
send us the result
db=# EXPLAIN ANALYZE UPDATE s_apotik SET stock = 100 WHERE obat_id='A';
regards
-Original Message-
From: [EMAIL PROTECTED]
[mailto:[EMAIL PROTECTED] On Behalf Of Tino Wildenhain
Sent: mardi 6
Why not just query adjacent databases, rather than copying the data around?
The reasons I didn't choose this way were:
1) I didn't think there's a way to write a query that can act on the data in
two
Databases as though it was all in one, and I didn't want to get into merging
multiple database
Richard Huxton dev@archonet.com writes:
Josep Maria Pinyol Fontseca wrote:
Windows XP client box with psql version 8.1.1 versus Windows XP server:
select * from table; - 60 seconds aprox. to obtain a results
Network utilization: 3%
The 60 seconds sounds suspiciously like a
Richard Huxton dev@archonet.com writes:
Josep Maria Pinyol Fontseca wrote:
Network utilization: 0%
It's *got* to be the network configuration on the client machine.
We've seen gripes of this sort before --- check the list archives for
possible fixes. I seem to recall something about a QoS
Dear Gurus,
Version: 7.4.6
I use a query on a heavily indexed table which picks a wrong index
unexpectedly. Since this query is used in response to certain user
interactions thousands of times in succession (with different constants),
500ms is not affordable for us. I can easily work around
Hi,We´ve a SELECT that even without ORDER BY is returning the rows in the order that we liked but when we add the ORDER BY clause the runtime and costs are much bigger.We have to use ORDER BY otherwise in some future postgresql version probably it will not return in the correct order
It's *got* to be the network configuration on the client machine.
We've seen gripes of this sort before --- check the list archives for
possible fixes. I seem to recall something about a QoS patch, as
well as suggestions to get rid of third-party packages that might be
interfering with
On Wed, Dec 21, 2005 at 07:03:00PM +0100, Sz?cs Gbor wrote:
Version: 7.4.6
[...]
Query is:
SELECT idopont WHERE muvelet = x ORDER BY idopont LIMIT 1.
I expected the planner to choose the index on muvelet, then sort by idopont.
Instead, it took the other index.
I think the planner is
=?ISO-8859-2?Q?Sz=FBcs_G=E1bor?= [EMAIL PROTECTED] writes:
Query is:
SELECT idopont WHERE muvelet = x ORDER BY idopont LIMIT 1.
Much the best solution for this would be to have an index on
(muvelet, idopont)
--- perhaps you can reorder the columns of muvelet_vonalkod_muvelet
instead of
Carlos Benkendorf [EMAIL PROTECTED] writes:
Table iparq.arript
Column | Type | Modifiers
---+---+---
anocalc | numeric(4,0) | not null
cadastro | numeric(8,0) | not
On Sun, Dec 18, 2005 at 01:10:21AM -, Ben Trewern wrote:
I know I should be writing these in C but that's a bit beyond me. I
was
going to try PL/Python or PL/Perl or even PL/Ruby. Has anyone any
idea
which language is fastest, or is the data access going to swamp the
overhead
of
On Wed, Dec 21, 2005 at 12:06:47PM +0100, Steinar H. Gunderson wrote:
On Sun, Dec 18, 2005 at 01:10:21AM -, Ben Trewern wrote:
I know I should be writing these in C but that's a bit beyond me. I was
going to try PL/Python or PL/Perl or even PL/Ruby. Has anyone any idea
which
On Wed, Dec 21, 2005 at 02:24:42PM -0700, Michael Fuhr wrote:
The difference is clear only in specific cases; just because you
saw a 10x increase in some cases doesn't mean you can expect that
kind of increase, or indeed any increase, in others. I've seen
PL/pgSQL beat all other PL/*
On Wed, Dec 21, 2005 at 10:38:10PM +0100, Steinar H. Gunderson wrote:
On Wed, Dec 21, 2005 at 02:24:42PM -0700, Michael Fuhr wrote:
The difference is clear only in specific cases; just because you
saw a 10x increase in some cases doesn't mean you can expect that
kind of increase, or indeed
Juan Casero wrote:
Can you elaborate on the reasons the opteron is better than the Xeon when it
comes to disk io? I have a PostgreSQL 7.4.8 box running a DSS. One of our
Opterons have 64-bit IOMMU -- Xeons don't. That means in 64-bit mode,
transfers to 4GB, the OS must allocated the
I restored the table in another database and repeated the analyze again with original column definitions (numeric):With order by: Sort (cost=212634.30..213032.73 rows=159374 width=897) (actual time=9286.817..9865.030 rows=167710 loops=1) Sort Key: anocalc, cadastro, codvencto, parcela - Index
On Wed, Dec 21, 2005 at 03:10:28PM -0700, Michael Fuhr wrote:
That's funny, my biggest problems with PL/PgSQL have been (among others)
exactly with large result sets...
Out of curiosity, do you have a simple test case? I'd be interested
in seeing what you're doing in PL/pgSQL that's
I am currently using a dual Opteron (248) single core system (RAM
PC3200) and for a change I am finding that the bottleneck is not disk
I/O but CPU/RAM (not sure which). The reason for this is that the most
frequently accessed tables/indexes are all held in RAM and when
querying the database there
Hi all,
On a user's request, I recently added MySQL support to my backup
program which had been written for PostgreSQL exclusively until now.
What surprises me is that MySQL is about 20%(ish) faster than PostgreSQL.
Now, I love PostgreSQL and I want to continue recommending it as the
* Madison Kelly ([EMAIL PROTECTED]) wrote:
If the performace difference comes from the 'COPY...' command being
slower because of the automatic quoting can I somehow tell PostgreSQL
that the data is pre-quoted? Could the performance difference be
something else?
I doubt the issue is with
On Thu, Dec 22, 2005 at 02:08:23AM +0100, Steinar H. Gunderson wrote:
On Wed, Dec 21, 2005 at 03:10:28PM -0700, Michael Fuhr wrote:
That's funny, my biggest problems with PL/PgSQL have been (among others)
exactly with large result sets...
Out of curiosity, do you have a simple test case?
On Wednesday 21 December 2005 20:14, Stephen Frost wrote:
* Madison Kelly ([EMAIL PROTECTED]) wrote:
If the performace difference comes from the 'COPY...' command being
slower because of the automatic quoting can I somehow tell PostgreSQL
that the data is pre-quoted? Could the performance
I just sent my boss an email asking him for a Sun v20z with dual 2.2 Ghz
opterons, 2 Gigs of RAM and RAID 1. I would have liked a better server
capable of RAID but that seems to be out of his budget right now. Ok so I
assume I get this Sun box. Most likely I will go with Linux since it is a
What version of postgres?
Copy has been substantially improved in bizgres and also in 8.1.
- Luke
--
Sent from my BlackBerry Wireless Device
-Original Message-
From: [EMAIL PROTECTED] [EMAIL PROTECTED]
To: pgsql-performance@postgresql.org
AFAIK there are no licensing costs for solaris, unless you are talking
about a software support agreement, which is not required.
Juan Casero wrote:
I just sent my boss an email asking him for a Sun v20z with dual 2.2 Ghz
opterons, 2 Gigs of RAM and RAID 1. I would have liked a better
Michael Fuhr [EMAIL PROTECTED] writes:
Try looping through two million rows with PL/Perl or PL/Tcl and
you'll probably see significantly worse performance than with
PL/pgSQL -- so much worse that I'd be surprised to see those languages
make up the difference with whatever processing they'd be
On Thu, 22 Dec 2005, Harry Jackson wrote:
I am currently using a dual Opteron (248) single core system (RAM
PC3200) and for a change I am finding that the bottleneck is not disk
I/O but CPU/RAM (not sure which). The reason for this is that the most
frequently accessed tables/indexes are all
Hi Juan,
Solaris 10 license is for free.. Infact I believe you do receive the
media with Sun Fire V20z. If you want support then there are various
pay plans depending on the level of support. If not your license
allows you Right to Use anyway for free.
That said I haven't done much testing
Stephen Frost wrote:
* Madison Kelly ([EMAIL PROTECTED]) wrote:
If the performace difference comes from the 'COPY...' command being
slower because of the automatic quoting can I somehow tell PostgreSQL
that the data is pre-quoted? Could the performance difference be
something else?
I
Luke Lonergan wrote:
What version of postgres?
Copy has been substantially improved in bizgres and also in 8.1.
- Luke
Currently 7.4 (what comes with Debian Sarge). I have run my program on
8.0 but not since I have added MySQL support. I should run the tests on
the newer versions of both
Madison,
On 12/21/05 10:58 PM, Madison Kelly [EMAIL PROTECTED] wrote:
Ah, that makes a lot of sense (I read about the 'fsync' issue before,
now that you mention it). I am not too familiar with MySQL but IIRC
MyISAM is their open-source DB and InnoDB is their commercial one, ne?
If so, then I
Madison,
On 12/21/05 11:02 PM, Madison Kelly [EMAIL PROTECTED] wrote:
Currently 7.4 (what comes with Debian Sarge). I have run my program on
8.0 but not since I have added MySQL support. I should run the tests on
the newer versions of both DBs (using v4.1 for MySQL which is also
mature at
38 matches
Mail list logo
