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
> matu
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,
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 DBs
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 doub
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
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 a
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'
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 ser
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
Sent: Wed Dec 21 21:03
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
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 perfo
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
* 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 wi
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
dat
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
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 cont
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 ->
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 mem
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 i
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/* challe
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 l
> 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
Carlos Benkendorf <[EMAIL PROTECTED]> writes:
> Table "iparq.arript"
> Column | Type | Modifiers
> ---+---+---
> anocalc | numeric(4,0) | not null
> cadastro | numeric(8,0)
=?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"
instea
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 g
> > 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
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 anym
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 t
Richard Huxton 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 patch", as
wel
Richard Huxton writes:
> Josep Maria Pinyol Fontseca wrote:
> > Windows XP client box with psql version 8.1.1 versus Windows XP server:
> > select * from ; -> 60 seconds aprox. to obtain a results
> > Network utilization: 3%
The 60 seconds sounds suspiciously like a DNS problem.
--
>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
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 dé
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 sm
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
>
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
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 con
Josep Maria Pinyol Fontseca wrote:
Linux box with psql version 7.2.1 versus Windows XP server:
select * from ; -> 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 ; -> 60 seconds aprox. to obt
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 ps
38 matches
Mail list logo
