Skip site navigation (1) Skip section navigation (2)

Re: Large databases, performance

From: "Shridhar Daithankar" <shridhar_daithankar(at)persistent(dot)co(dot)in>
To: pgsql-performance(at)postgresql(dot)org, pgsql-hackers(at)postgresql(dot)org,pgsql-general <pgsql-general(at)postgresql(dot)org>,"pankaj M(dot) Tolani" <pankaj(at)pspl(dot)co(dot)in>
Subject: Re: Large databases, performance
Date: 2002-10-03 16:17:03
Message-ID: 3D9CBAD7.23509.A908C61@localhost (view raw or flat)
Thread:
Lists: pgsql-generalpgsql-hackerspgsql-performancepgsql-sql
On 3 Oct 2002 at 11:57, Robert Treat wrote:

> NOTE: Setting follow up to the performance list
> 
> Funny that the status quo seems to be if you need fast selects on data
> that has few inserts to pick mysql, otherwise if you have a lot of
> inserts and don't need super fast selects go with PostgreSQL; yet your
> data seems to cut directly against this. 

Well, couple of things..

The number of inserts aren't few. it's 5000/sec.required in the field Secondly 
I don't know really but postgresql seems doing pretty fine in parallel selects. 
If we use mysql with transaction support then numbers are really close..

May be it's time to rewrite famous myth that postgresql is slow. When properly 
tuned or given enough head room, it's almost as fast as mysql..

> I'm curious, did you happen to run the select tests while also running
> the insert tests? IIRC the older mysql versions have to lock the table
> when doing the insert, so select performance goes in the dumper in that
> scenario, perhaps that's not an issue with 3.23.52? 

IMO even if it locks tables that shouldn't affect select performance. It would 
be fun to watch when we insert multiple chunks of data and fire queries 
concurrently. I would be surprised if mysql starts slowing down..

> It also seems like the vacuum after each insert is unnecessary, unless
> your also deleting/updating data behind it. Perhaps just running an
> ANALYZE on the table would suffice while reducing overhead.

I believe that was vacuum analyze only. But still it takes lot of time. Good 
thing is it's not blocking..

Anyway I don't think such frequent vacuums are going to convince planner to 
choose index scan over sequential scan. I am sure it's already convinced..

Regards,
 Shridhar

-----------------------------------------------------------
Shridhar Daithankar
LIMS CPE Team Member, PSPL.
mailto:shridhar_daithankar(at)persistent(dot)co(dot)in
Phone:- +91-20-5678900 Extn.270
Fax  :- +91-20-5678901 
-----------------------------------------------------------


In response to

Responses

pgsql-performance by date

Next:From: Greg CopelandDate: 2002-10-03 16:23:28
Subject: Re: [HACKERS] Large databases, performance
Previous:From: Justin CliftDate: 2002-10-03 16:16:06
Subject: Re: [HACKERS] Large databases, performance

pgsql-hackers by date

Next:From: Nigel J. AndrewsDate: 2002-10-03 16:17:27
Subject: Re: anoncvs and diff
Previous:From: Justin CliftDate: 2002-10-03 16:16:06
Subject: Re: [HACKERS] Large databases, performance

pgsql-sql by date

Next:From: Greg CopelandDate: 2002-10-03 16:23:28
Subject: Re: [HACKERS] Large databases, performance
Previous:From: Justin CliftDate: 2002-10-03 16:16:06
Subject: Re: [HACKERS] Large databases, performance

pgsql-general by date

Next:From: Brian WolfDate: 2002-10-03 16:22:53
Subject: Re: Rép. : [GENERAL] newbie
Previous:From: Justin CliftDate: 2002-10-03 16:16:06
Subject: Re: [HACKERS] Large databases, performance

Privacy Policy | About PostgreSQL
Copyright © 1996-2014 The PostgreSQL Global Development Group