>> Afaik, your original posting said postgresql was 3 times slower than
>> mysql and that you are going to leave this list now. This implied
>> that you have made your decision between postgresql and mysql,
>> taking mysql because it is faster.
>
> Well, that shows what you get for making implicati
Andrew Sullivan <[EMAIL PROTECTED]> writes:
> How could it be the transport affects the time for the query as
> reported by the back end?
How much data is being sent back by the query?
Do you have SSL enabled? SSL encryption overhead is nontrivial,
especially if any renegotiations happen.
On Fri, Jul 04, 2003 at 07:55:12PM +0200, Vincent van Leeuwen wrote:
> But since this only relates to making and breaking TCP connections,
> I don't think this is relevant for a larger query time. It's
> probably normal for a TCP connection to be slightly slower than a
> unix socket, but I don't t
>Afaik, your original posting said postgresql was 3 times slower than mysql
>and that you are going to leave this list now. This implied that you have
>made your decision between postgresql and mysql, taking mysql because it is
>faster.
Well, that shows what you get for making implications. The c
> I am about to propose a patch that will cause the default shared_buffers
> to be more realistic, say 1000, on machines where the kernel will allow
> it. Not sure if people will let me get away with applying it
> post-feature-freeze, but if so that would change the terms of this
> debate noticeab
Tom,
> I am about to propose a patch that will cause the default shared_buffers
> to be more realistic, say 1000, on machines where the kernel will allow
> it. Not sure if people will let me get away with applying it
> post-feature-freeze, but if so that would change the terms of this
> debate no
Josh Berkus <[EMAIL PROTECTED]> writes:
>> ---snip---
>> By default, PostgreSQL is configured to run on minimal hardware. As
>> a result, some tuning of your installation will be necessary before
>> using it for anything other than extremely small databases. At the
>> very least, it will probably
People:
> I think I did indeed speak too soon, as the criticism is a fair one:
> nowhere in the installation instructions or the "getting started"
> docs does it say that you really ought to do some tuning once you
> have the system installed. Can I suggest for the time being that
> something alo
On Fri, Jul 04, 2003 at 08:07:18PM +0200, Arjen van der Meijden wrote:
> > Andrew Sullivan wrote:
> > results under production conditions, and not bother to read
> > even the basic "quickstart"-type stuff that is kicking
> > around.
> Then please point out where it sais, in the documentation, tha
Why is such a simple list of questions not somewhere in the
documentation? :(
Of course a few of your questions are relatively case-dependent, but the
others are very general. Such information should be in the documentation
and easy to access :)
Regards,
Arjen
> Stephan Szabo wrote a nice list
> Andrew Sullivan wrote:
> I cannot, for the life of me, understand how anyone can
> install some software which is supposed to provide meaningful
> results under production conditions, and not bother to read
> even the basic "quickstart"-type stuff that is kicking
> around.
Then please point
> If I connect using -h 127.0.0.1, however, I can _sometimes_ get the
> query to take as long as 1200 msec. The effect is sporadic (of
SSL plays havoc with our system when using local loopback for the host
on both Solaris 7 and 8. It was probably key renegotiation which 7.4
has addressed.
si
http://grotto11.com/blog/slash.html?+1039831658
Summary: IE and IIS cheat at TCP level by leaving out various SYN and ACK
packets, thereby making IE requests from IIS servers blazingly fast, and
making IE requests to non-IIS servers infuriatingly slow.
But since this only relates to making and br
'K, this is based on "old information", I don't know if Sun changed it
'yet again' ... but, when I was working at the University, one of our IT
directors gave me a report that deal with something Sun did (god, I'm so
detailed here, eh?) to "mimic" how Microsoft broke the TCP/IP protocol
... the r
Josh Berkus <[EMAIL PROTECTED]> writes:
> Tom Comments:
>> I was arguing awhile back for bumping the default shared_buffers up,
>> but the discussion trailed off with no real resolution.
> I think we ran up against the still far-too-low SHMMAX settings in most
> *nixes. We could raise this defa
Hi all,
We're run into a rather odd problem here, and we're puzzling out
what's going on. But while we do, I thought I'd see if anyone else
has anything similar to report.
This is for 7.2.4 on Solaris 8.
We have a query for which EXPLAIN ANALYSE on a local psql connection
always returns a time
Brian,
Howdy! I'm Josh Berkus, I'm also on the Core Team for PostgreSQL, and I
wanted to give some closure on your issue before you quit with a bad taste in
your mouth.
Your posting hit a sore point in the collective PostgreSQL community, so you
got a strong reaction from several people on th
On Fri, Jul 04, 2003 at 12:10:46PM -0400, Brian Tarbox wrote:
> I am not allowed to share schemas...sorry but thats what the contract says.
> The queries represent code, thus intellectual property, thus I can't post
> them.
If you ask for help, but say, "I can't tell you anything," no-one
will be
On Fri, 4 Jul 2003, Brian Tarbox wrote:
> > I don't think Brian has any interest in being helped.
> >I suspect he'd made up his mind already.
>
>
> With all due respect Tom, I don't think I'm the one demonstrating a closed
> mind.
> Rather than trying to figure out whats going on in my head, how
Kaarel:
(cross-posted back to Performance because I don't want to post twice on the
same topic)
> The problem is that people often benchmark the so called vanilla
> installation of PostgreSQL.
> I remember a discussion in the general list about having multiple
> default conf files to choose fro
My goodness people!! If you are just going to bash people who are trying to
learn PostgreSQL then you have no chance of ever getting new people using
it! Cut out this crap and do what this list is meant to do, which is, I'm
assuming, helping people figure out why their installations aren't runnin
> I'm not saying (and never did say) that postgres could not be fast.
> All I ever said was that with the same minimal effort applied to both
> DBs, postgres was slower.
Afaik, your original posting said postgresql was 3 times slower than mysql
and that you are going to leave this list now. This i
> I don't think Brian has any interest in being helped.
>I suspect he'd made up his mind already.
With all due respect Tom, I don't think I'm the one demonstrating a closed
mind.
Rather than trying to figure out whats going on in my head, how about
figuring out whats going on in my database? :-)
That would be something that I'd like to see. Being new to PostgreSQL some
of the basics of tuning the database were a little hard to find. The reason
people go with MySQL is because it's fast and easy to use. That's why I had
been using it for years. Then when a problem came along and I couldn
On Friday 04 July 2003 20:56, Andrew Sullivan wrote:
> On Fri, Jul 04, 2003 at 04:35:03PM +0200, Michael Mattox wrote:
> > I see this as a major problem. How many people run postgres, decide it's
> > too slow and give up without digging into the documentation or coming to
> > this group? This see
On Fri, Jul 04, 2003 at 04:35:03PM +0200, Michael Mattox wrote:
> I see this as a major problem. How many people run postgres, decide it's
> too slow and give up without digging into the documentation or coming to
> this group? This seems to be pretty common. Even worst, they tell 10
> others h
On Friday 04 July 2003 20:36, Rod Taylor wrote:
> > 2. Postgresql uses shared memory being process based architecture. Mysql
> > uses process memory being threaded application. It does not need kernel
> > settings to work and usually works best it can.
>
> MySQL has other issues with the kernel du
> 2. Postgresql uses shared memory being process based architecture. Mysql uses
> process memory being threaded application. It does not need kernel settings to
> work and usually works best it can.
MySQL has other issues with the kernel due to their threading choice
such as memory limits per
hi,
At 20:19 04.07.2003 +0530, Shridhar Daithankar wrote:
[...]
On a positive note, me and Josh are finishing a bare bone performance article
where will be this article published?
that would answer lot of your questions. I am counting on you to provide
valuable feedback. I expect it out tomorrow
On 4 Jul 2003 at 16:35, Michael Mattox wrote:
> I see this as a major problem. How many people run postgres, decide it's
> too slow and give up without digging into the documentation or coming to
> this group? This seems to be pretty common. Even worst, they tell 10
> others how slow Postgres i
"Brian Tarbox" <[EMAIL PROTECTED]> writes:
> I'm not permitted to post the actual tables as per company policy.
Nobody wants to see your data, only the table schemas and queries. If
you feel that even that contains some sensitive information, just rename
the table and field names to something mea
> This appears to be a "yes" answer to my question above. Out of the
> box, PostgreSQL is set up to be able to run on a 1992-vintage SGI
> Indy with 8 M of RAM (ok, I may be exaggerating, but only by a bit);
> it is not tuned for performance. Running without even tweaking the
> shared buffers is
> Please understand the limits of how much information a consultant can submit
> to an open list like this about a client's confidential information. I've
> answered every question I _can_ answer and when I get hostility in response
> all I can do is sigh and move on.
Is there any chance you coul
On Fri, Jul 04, 2003 at 10:07:46AM -0400, Brian Tarbox wrote:
> 512 mb memory, latest production versions of each database. By vanilla
> RedHat I mean that I installed RH on a clean system, said install everything
> and did no customization of RH settings.
Does that include no customization of th
Rod Taylor <[EMAIL PROTECTED]> writes:
>> It was bit too vague to be a comfortable DB tuning problem.
> Completely too little information, and it stopped with Tom asking for
> additional information.
There was something awfully fishy about that. Brian was saying that he
got a seqscan plan out of
On 4 Jul 2003 at 10:07, Brian Tarbox wrote:
> Ok, I'll give more data :-)
>
> Under both MySql and Postgres the tests were run on a variety of systems,
> all with similar results. My own personal testing was done on a P4 2.4Mhz,
> 512 mb memory, latest production versions of each database. By v
Ok, I'll give more data :-)
Under both MySql and Postgres the tests were run on a variety of systems,
all with similar results. My own personal testing was done on a P4 2.4Mhz,
512 mb memory, latest production versions of each database. By vanilla
RedHat I mean that I installed RH on a clean sys
"Brian Tarbox" <[EMAIL PROTECTED]> writes:
> I recently took a system from MySQL to Postgres. Same HW, SW, same data.
> The major operations where moderately complex queries (joins on 8 tables).
> The results we got was that Postgres was fully 3 times slower than MySql.
> We were on this list a
> I recently took a system from MySQL to Postgres. Same HW, SW, same data.
> The major operations where moderately complex queries (joins on 8 tables).
>
> The results we got was that Postgres was fully 3 times slower than MySql.
> We were on this list a fair bit looking for answers and tried all
On Fri, 2003-07-04 at 09:20, Shridhar Daithankar wrote:
> On 4 Jul 2003 at 9:11, Rod Taylor wrote:
>
> > > Unless you provide these, it's difficult to help..
> >
> > http://archives.postgresql.org/pgsql-performance/2003-05/msg00299.php
>
> Well, even in that thread there wasn't enough informatio
On 2 Jul 2003 at 16:17, Mats Kling wrote:
>
> Hi all!
>
> I have a big trouble with a database and hope you can help out on how to
> improve the time vacuum takes.
>
> The database grovs to ~60Gb and after a 'vacuum full' it's ~31Gb, after
> about a week the database it up to 55-60Gb again an
On 4 Jul 2003 at 9:11, Rod Taylor wrote:
> > Unless you provide these, it's difficult to help..
>
> http://archives.postgresql.org/pgsql-performance/2003-05/msg00299.php
Well, even in that thread there wasn't enough information I asked for in other
mail. It was bit too vague to be a comfortable
> Unless you provide these, it's difficult to help..
http://archives.postgresql.org/pgsql-performance/2003-05/msg00299.php
Note the thread with Tom and Brian.
signature.asc
Description: This is a digitally signed message part
On Friday 04 July 2003 17:57, Brian Tarbox wrote:
> I recently took a system from MySQL to Postgres. Same HW, SW, same data.
> The major operations where moderately complex queries (joins on 8 tables).
>
> The results we got was that Postgres was fully 3 times slower than MySql.
> We were on this
On Friday 04 July 2003 18:16, Michael Mattox wrote:
> > I'm actually leaving this list but I can answer this question.
> > Our results
> > were with a single user and we were running Inodb. We were running on
> > RedHat 8.0 / 9.0 with vanilla linux settings.
>
> That's funny, you make a statement
> I'm actually leaving this list but I can answer this question.
> Our results
> were with a single user and we were running Inodb. We were running on
> RedHat 8.0 / 9.0 with vanilla linux settings.
That's funny, you make a statement that Postgres was 3 times slower than
MySQL and then you prompt
I'm actually leaving this list but I can answer this question. Our results
were with a single user and we were running Inodb. We were running on
RedHat 8.0 / 9.0 with vanilla linux settings.
Brian
-Original Message-
From: Michael Mattox [mailto:[EMAIL PROTECTED]
Sent: Friday, July 04, 2
> I recently took a system from MySQL to Postgres. Same HW, SW, same data.
> The major operations where moderately complex queries (joins on 8 tables).
>
> The results we got was that Postgres was fully 3 times slower than MySql.
> We were on this list a fair bit looking for answers and tried all
That's one heck of a poor estimate for the number of rows returned.
> -> Seq Scan on mss_fwevent (cost=0.00..223312.60 rows=168478 width=12) (actual
> time=24253.66..24319.87 rows=320 loops=1)
signature.asc
Description: This is a digitally signed message part
I recently took a system from MySQL to Postgres. Same HW, SW, same data.
The major operations where moderately complex queries (joins on 8 tables).
The results we got was that Postgres was fully 3 times slower than MySql.
We were on this list a fair bit looking for answers and tried all the
stan
On Friday 04 Jul 2003 11:03 am, Rafal Kedziorski wrote:
> Hi,
>
> has anybody tested PostgreSQL 7.3.x tables agains MySQL 4.0.12/13 with
> InnoDB?
Lots of people probably. The big problem is that unless the tester's setup
matches your intended usage the results are of little worth.
For the tests
PostgreSQL (as being a really advanced RDBMS),
generally requires some tuning in order to get
the best performance.
Your best bet is to try both.
Also check to see IF mysql has
-Referential integrity
-subselects
-transactions
-(other usefull features like arrays,user defined types,etc..)
(its pr
Hi,
has anybody tested PostgreSQL 7.3.x tables agains MySQL 4.0.12/13 with InnoDB?
Regards,
Rafal
---(end of broadcast)---
TIP 6: Have you searched our list archives?
http://archives.postgresql.org
53 matches
Mail list logo
