RE: [ilugd] Postgres vs oracle

2003-10-19 Thread Tarun Upadhyay
Incidentally,
this is also true for most commerical databases. The space of
delete rows is not returned to OS automatically.
while shutting down the database is not necessary but trying to
return space back to OS does have a significant performance penalty and is
not recommeneded on productions systems (at least in oracle and SQL Server).

Tarun

-Original Message-
From: [EMAIL PROTECTED]
[mailto:[EMAIL PROTECTED] On
Behalf Of Gurpreet Singh Sachdeva
Sent: Saturday, October 18, 2003 2:10 AM
To: The Linux-Delhi mailing list; The Linux-Delhi mailing list
Subject: RE: [ilugd] Postgres vs oracle


 Correct! 

To be more precise:

The standard form of VACUUM is best used with the goal of maintaining a
fairly level steady-state usage of disk space. The standard form finds old
tuples and makes their space available for re-use within the table, but it
does not try very hard to shorten the table file and return disk space to
the operating system. If you need to return disk space to the operating
system you can use VACUUM FULL --- but what's the point of releasing disk
space that will only have to be allocated again soon? Moderately frequent
standard VACUUMs are a better approach than infrequent VACUUM FULLs for
maintaining heavily-updated tables.

Recommended practice for most sites is to schedule a database-wide VACUUM
once a day at a lowusage time of day, supplemented by more frequent
vacuuming of heavily-updated tables if necessary. (If you have multiple
databases in an installation, don't forget to vacuum each one; the vacuumdb
script may be helpful.) Use plain VACUUM, not VACUUM FULL, for routine
vacuuming for space recovery. 

VACUUM FULL is recommended for cases where you know you have deleted the
majority of tuples in a table, so that the steady-state size of the table
can be shrunk substantially with VACUUM FULL's more aggressive approach. 

If you have a table whose contents are deleted completely every so often,
consider doing it with TRUNCATE rather than using DELETE followed by VACUUM.

Gurpreet Singh Sachdeva

-Original Message- 
From: Raj Mathur [mailto:[EMAIL PROTECTED] 
Sent: Thu 10/16/2003 5:38 PM 
To: The Linux-Delhi mailing list 
Cc: 
Subject: Re: [ilugd] Postgres vs oracle



-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1

 Ambar == Ambar Roy [EMAIL PROTECTED] writes:

  Surely NO...so we would certainly be interested to know
some
 of your 
Ambar Biggest Internet Sites running on open source.
 Geocrawler use Postgres.
Ambar Intresting thing about Geocrawler  AudioGalaxy using
Ambar postgres was that both of these sites seemed to go
offline
Ambar for daily maintainence during the middle of the day here
in
Ambar India. Both the sites ran Postgresql, and were probably
Ambar running a daily database cleanup. IMHO this is what has
Ambar kept me away from considering postgresql for serious
Ambar databases. Has this issue of regular database
maintainence
Ambar been solved by the recent versions of postgresql?

PostgreSQL (PgSQL) has two types of ``cleanup'': vacuum and vacuum
full.  The first (plain vacuum) merely marked unused (deleted) disk
clusters as free but does not compact the physical database.  The
second (vacuum full) does all that and also physically compacts the
database on disk.

Using vacuum full will lock up your database, no queries or
transactions will be possible while it is running.  However most
databases achieve a sort of `steady state' (roughly the same number
of
records being added and deleted regularly) and plain vacuum suffices
for that.  Transactions are possible during vacuum, and most
installations will prefer to use that periodically over vacuum full.
It's only if your database sizes vary wildly over the course of time
that you'll need to use vacuum full (and consequently bring the
system
down for maintenance).

The above is from my understanding of PgSQL, would appreciate
clarifications in case I've missed anything out.

Ambar Another intresting thing about postgresql is that while
the
Ambar web hosting control panels on Linux used to only support
Ambar MySQL, cPanel  Plesk now have support for Postgresql. To
Ambar me this is a good sign. Now even smaller sites can start
Ambar using Postgresql.

Regards,

- -- Raju
- --
Raj Mathur[EMAIL PROTECTED]
http://kandalaya.org/
   GPG: 78D4 FC67 367F 40E2 0DD5  0FEF C968 D0EF CC68 D17F
  It is the mind that moves
-BEGIN PGP SIGNATURE-
Version: GnuPG v1.0.7 (GNU/Linux

RE: [ilugd] Postgres vs oracle

2003-10-19 Thread Tarun Upadhyay
Did some research over the weekend.

First of all some good news:
Heavy duty sites that run Postgres include;
A) RubyForge (rubyforge.org). They have 300K records. Not too many but
moderately high.
B) .org domain.
c) sourceforge used to run postgres. AFAIK, they moved out because IBM made
that a condition for funding them and not because of any issues with
postgres.

Now, the bad news:

Postgres is still not clusterable. What postgres calls clustering is using
triggers to copy data from one server to another. This is not what is
usually meant by database clusters. There would be no good way to handle
globally unique columns or handle conflicting writes and transactions in
general.

(If you call using triggers and copy clustering. I have a geographically
distributed mysql cluster that uses rsync and cron !!)

When I say database cluster, I mean that you put a bullet thru one of the
servers while your query is running and your query still returns the right
results as if nothing happened. This can be achieved by something like
mounting RAID-5 (or raid-10) (software or hardware) on two postgres boxes to
somehow mirror data over two servers and the two servers somehow aware which
of them is writing which block so that they do not knock each other's
writes. Seems like that is pretty far away. To be precise, it is not really
RAID but actually raid-like-transparent-mirroring-over-network and does not
exist in mainstream linux kernel. However, it seems oracle is giving similar
technology (called
OpenGFS)(http://otn.oracle.com/tech/linux/open_source.html) as well as tools
to run this kind of network over firewire or fibre. (100 Mbps might end up
being too slow for such an exercise). IMHO, oracle is giving this technology
away so that they can sell more RAC licenses on linux. However, oracle or
not, I would prefer seeing something similar to OpenGFS integrated into main
stream kernel (I believe the closest today in mainstream kernel would be
mounting network block devices in somekind of software RAID volumes). 

Other than clustering, things that are currently not in postges but exists
in oracle:
A) materialized views (views that are calculated early on and not
just-in-time)
B) index-organized tables (where the entire table is in index. Great for
performance on narrow tables)
C) database links (this is linking columns to point at values in other
databases)
D) point-in-time recovery (restore database state to as on XXX)
E) nested transactions
F) savepoint
G) good cursor support (Right now executing a query fetches the entire
result set in memory. This is not scalable). This is easy to do for simple
cases but probably very difficult for queries inside transactions
H) execute batch /bulk updates etc. (there is copy but that is not standard)
i) peripheral tools. Lot of people use oracle forms and reports. I have not
heard of anything similar for postgres. It would be also nice to have some
good migration tools.
J) tablespaces
K) multi-column function-based indexes

Many things just came in 7.3 and are not completely tested. They inculded:
A) stored procedures that can return result sets (table functions)
B) schema support
C) prepared queries
D) dependancy tracking
E) good secuirty and priviledge model (before 7.3 it was rather elementary)
F) improved internationalization support (this still has to go some way)

tarun


___
ilugd mailing list
[EMAIL PROTECTED]
http://frodo.hserus.net/mailman/listinfo/ilugd


Re: [ilugd] Postgres vs oracle

2003-10-18 Thread Ambar Roy
 The standard form of VACUUM is best used with the goal of maintaining a
fairly level steady-state usage of disk space. The standard form finds old
tuples and makes their space available for re-use within the table, but it
does not try very hard to shorten the table file and return disk space to
the operating system. If you need to return disk space to the operating
system you can use VACUUM FULL --- but whats the point of releasing disk
space that will only have to be allocated again soon? Moderately frequent
standard VACUUMs are a better approach than infrequent VACUUM FULLs for
maintaining heavily-updated tables.

 Recommended practice for most sites is to schedule a database-wide VACUUM
once a day at a lowusage time of day, supplemented by more frequent
vacuuming of heavily-updated tables if necessary. (If you have multiple
databases in an installation, dont forget to vacuum each one; the vacuumdb
script may be helpful.) Use plain VACUUM, not VACUUM FULL, for routine
vacuuming for space recovery.

So does VACUUM require the database to be taken offline? Or was this an
issue with older versions of pgSQL? As I don't see the Geocrawler under
maintainence pages nowadays. There was a time when I only saw the under
maintainence page at Geocrawler!!

Ambar Roy


___
ilugd mailing list
[EMAIL PROTECTED]
http://frodo.hserus.net/mailman/listinfo/ilugd


Re: [ilugd] Postgres vs oracle

2003-10-18 Thread Raj Mathur
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1

 Ambar == Ambar Roy [EMAIL PROTECTED] writes:

Ambar [snip].

Ambar So does VACUUM require the database to be taken offline? Or
Ambar was this an issue with older versions of pgSQL? As I don't
Ambar see the Geocrawler under maintainence pages nowadays. There
Ambar was a time when I only saw the under maintainence page at
Ambar Geocrawler!!

Haven't used the newer versions of PostgreSQL, but with 7.2.3 (with
which I'm familiar) VACUUM doesn't require any special handling, while
VACUUM FULL locks up the database until the command completes.  VACUUM
FULL also doesn't  run while the database is in use, e.g. when
transactions are pending.

Regards,

- -- Raju
- -- 
Raj Mathur[EMAIL PROTECTED]  http://kandalaya.org/
   GPG: 78D4 FC67 367F 40E2 0DD5  0FEF C968 D0EF CC68 D17F
  It is the mind that moves
-BEGIN PGP SIGNATURE-
Version: GnuPG v1.0.7 (GNU/Linux)
Comment: Processed by Mailcrypt 3.5.6 and Gnu Privacy Guard http://www.gnupg.org/

iD8DBQE/kYhuyWjQ78xo0X8RArHKAKCMHfW3tm8oo+Z4y3Cy2vV1R5TQtwCeO/Rh
0MCKClGa72LhpXlaXmcbBVI=
=A7mB
-END PGP SIGNATURE-

___
ilugd mailing list
[EMAIL PROTECTED]
http://frodo.hserus.net/mailman/listinfo/ilugd


Re: [ilugd] Postgres vs oracle

2003-10-17 Thread shantanu
Some more information, some numbers from mysql:
http://www.mysql.com/information/features.html
http://www.mysql.com/information/benchmarks-old.html
regards
shantanu
On Thu, 16 Oct 2003 17:38:34 +0530, Raj Mathur [EMAIL PROTECTED] 
wrote:

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
Ambar == Ambar Roy [EMAIL PROTECTED] writes:
  Surely NO...so we would certainly be interested to know some
 of your 
Ambar Biggest Internet Sites running on open source.
 Geocrawler use Postgres.
Ambar Intresting thing about Geocrawler  AudioGalaxy using
Ambar postgres was that both of these sites seemed to go offline
Ambar for daily maintainence during the middle of the day here in
Ambar India. Both the sites ran Postgresql, and were probably
Ambar running a daily database cleanup. IMHO this is what has
Ambar kept me away from considering postgresql for serious
Ambar databases. Has this issue of regular database maintainence
Ambar been solved by the recent versions of postgresql?
PostgreSQL (PgSQL) has two types of ``cleanup'': vacuum and vacuum
full.  The first (plain vacuum) merely marked unused (deleted) disk
clusters as free but does not compact the physical database.  The
second (vacuum full) does all that and also physically compacts the
database on disk.
Using vacuum full will lock up your database, no queries or
transactions will be possible while it is running.  However most
databases achieve a sort of `steady state' (roughly the same number of
records being added and deleted regularly) and plain vacuum suffices
for that.  Transactions are possible during vacuum, and most
installations will prefer to use that periodically over vacuum full.
It's only if your database sizes vary wildly over the course of time
that you'll need to use vacuum full (and consequently bring the system
down for maintenance).
The above is from my understanding of PgSQL, would appreciate
clarifications in case I've missed anything out.
Ambar Another intresting thing about postgresql is that while the
Ambar web hosting control panels on Linux used to only support
Ambar MySQL, cPanel  Plesk now have support for Postgresql. To
Ambar me this is a good sign. Now even smaller sites can start
Ambar using Postgresql.
Regards,

- -- Raju
- -- Raj Mathur[EMAIL PROTECTED]  
http://kandalaya.org/
GPG: 78D4 FC67 367F 40E2 0DD5  0FEF C968 D0EF CC68 D17F
It is the mind that moves
-BEGIN PGP SIGNATURE-
Version: GnuPG v1.0.7 (GNU/Linux)
Comment: Processed by Mailcrypt 3.5.6 and Gnu Privacy Guard 
http://www.gnupg.org/

iD8DBQE/joo+yWjQ78xo0X8RAh/9AJ92FPCIhsOSYWwlOrgI610XI6IjtQCbBOCv
apkVPv4S87Ot14c7+YDzGwo=
=RF8Y
-END PGP SIGNATURE-
___
ilugd mailing list
[EMAIL PROTECTED]
http://frodo.hserus.net/mailman/listinfo/ilugd




___
ilugd mailing list
[EMAIL PROTECTED]
http://frodo.hserus.net/mailman/listinfo/ilugd


Re: [ilugd] Postgres vs oracle

2003-10-17 Thread shantanu
Please check
http://formation.espacecourbe.com/choosing/dbc_crashMe20001011.html
and some comparision reports
http://formation.espacecourbe.com/choosing/
Regards
shantanu


On 16 Oct 2003 12:15:25 +0530, Tarun Dua [EMAIL PROTECTED] wrote:

On Thu, 2003-10-16 at 11:35, Ambar Roy wrote:
 Geocrawler use Postgres.
Intresting thing about Geocrawler  AudioGalaxy using postgres was that 
both
of these sites seemed to go offline for daily maintainence during the 
middle
of the day here in India. Both the sites ran Postgresql, and were 
probably
running a daily database cleanup. IMHO this is what has kept me away 
from
considering postgresql for serious databases. Has this issue of regular
database maintainence been solved by the recent versions of postgresql?
I haven't heard about any horror stories on PostgreSQL lately although I
prefer MySQL till now.
I am planning a migration from MySQL to Postgres.
-Tarun
___
ilugd mailing list
[EMAIL PROTECTED]
http://frodo.hserus.net/mailman/listinfo/ilugd




___
ilugd mailing list
[EMAIL PROTECTED]
http://frodo.hserus.net/mailman/listinfo/ilugd


RE: [ilugd] Postgres vs oracle

2003-10-17 Thread Gurpreet Singh Sachdeva
 Correct! 

To be more precise:

The standard form of VACUUM is best used with the goal of maintaining a fairly level 
steady-state usage of disk space. The standard form finds old tuples and makes their 
space available for re-use within the table, but it does not try very hard to shorten 
the table file and return disk space to the operating system. If you need to return 
disk space to the operating system you can use VACUUM FULL --- but whats the point 
of releasing disk space that will only have to be allocated again soon? Moderately 
frequent standard VACUUMs are a better approach than infrequent VACUUM FULLs for 
maintaining heavily-updated tables.

Recommended practice for most sites is to schedule a database-wide VACUUM once a day 
at a lowusage time of day, supplemented by more frequent vacuuming of heavily-updated 
tables if necessary. (If you have multiple databases in an installation, dont 
forget to vacuum each one; the vacuumdb script may be helpful.) Use plain VACUUM, not 
VACUUM FULL, for routine vacuuming for space recovery. 

VACUUM FULL is recommended for cases where you know you have deleted the majority of 
tuples in a table, so that the steady-state size of the table can be shrunk 
substantially with VACUUM FULLs more aggressive approach. 

If you have a table whose contents are deleted completely every so often, consider 
doing it with TRUNCATE rather than using DELETE followed by VACUUM.

Gurpreet Singh Sachdeva

-Original Message- 
From: Raj Mathur [mailto:[EMAIL PROTECTED] 
Sent: Thu 10/16/2003 5:38 PM 
To: The Linux-Delhi mailing list 
Cc: 
Subject: Re: [ilugd] Postgres vs oracle



-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1

 Ambar == Ambar Roy [EMAIL PROTECTED] writes:

  Surely NO...so we would certainly be interested to know some
 of your 
Ambar Biggest Internet Sites running on open source.
 Geocrawler use Postgres.
Ambar Intresting thing about Geocrawler  AudioGalaxy using
Ambar postgres was that both of these sites seemed to go offline
Ambar for daily maintainence during the middle of the day here in
Ambar India. Both the sites ran Postgresql, and were probably
Ambar running a daily database cleanup. IMHO this is what has
Ambar kept me away from considering postgresql for serious
Ambar databases. Has this issue of regular database maintainence
Ambar been solved by the recent versions of postgresql?

PostgreSQL (PgSQL) has two types of ``cleanup'': vacuum and vacuum
full.  The first (plain vacuum) merely marked unused (deleted) disk
clusters as free but does not compact the physical database.  The
second (vacuum full) does all that and also physically compacts the
database on disk.

Using vacuum full will lock up your database, no queries or
transactions will be possible while it is running.  However most
databases achieve a sort of `steady state' (roughly the same number of
records being added and deleted regularly) and plain vacuum suffices
for that.  Transactions are possible during vacuum, and most
installations will prefer to use that periodically over vacuum full.
It's only if your database sizes vary wildly over the course of time
that you'll need to use vacuum full (and consequently bring the system
down for maintenance).

The above is from my understanding of PgSQL, would appreciate
clarifications in case I've missed anything out.

Ambar Another intresting thing about postgresql is that while the
Ambar web hosting control panels on Linux used to only support
Ambar MySQL, cPanel  Plesk now have support for Postgresql. To
Ambar me this is a good sign. Now even smaller sites can start
Ambar using Postgresql.

Regards,

- -- Raju
- --
Raj Mathur[EMAIL PROTECTED]  http://kandalaya.org/
   GPG: 78D4 FC67 367F 40E2 0DD5  0FEF C968 D0EF CC68 D17F
  It is the mind that moves
-BEGIN PGP SIGNATURE-
Version: GnuPG v1.0.7 (GNU/Linux)
Comment: Processed by Mailcrypt 3.5.6 and Gnu Privacy Guard 
http://www.gnupg.org/

iD8DBQE/joo+yWjQ78xo0X8RAh/9AJ92FPCIhsOSYWwlOrgI610XI6IjtQCbBOCv
apkVPv4S87Ot14c7+YDzGwo=
=RF8Y
-END PGP SIGNATURE-

___
ilugd mailing list
[EMAIL PROTECTED]
http://frodo.hserus.net/mailman/listinfo/ilugd



___
ilugd mailing list
[EMAIL PROTECTED]
http://frodo.hserus.net/mailman/listinfo/ilugd


Re: [ilugd] Postgres vs oracle

2003-10-16 Thread Raj Mathur
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1

 Ambar == Ambar Roy [EMAIL PROTECTED] writes:

  Surely NO...so we would certainly be interested to know some
 of your 
Ambar Biggest Internet Sites running on open source.
 Geocrawler use Postgres.
Ambar Intresting thing about Geocrawler  AudioGalaxy using
Ambar postgres was that both of these sites seemed to go offline
Ambar for daily maintainence during the middle of the day here in
Ambar India. Both the sites ran Postgresql, and were probably
Ambar running a daily database cleanup. IMHO this is what has
Ambar kept me away from considering postgresql for serious
Ambar databases. Has this issue of regular database maintainence
Ambar been solved by the recent versions of postgresql?

PostgreSQL (PgSQL) has two types of ``cleanup'': vacuum and vacuum
full.  The first (plain vacuum) merely marked unused (deleted) disk
clusters as free but does not compact the physical database.  The
second (vacuum full) does all that and also physically compacts the
database on disk.

Using vacuum full will lock up your database, no queries or
transactions will be possible while it is running.  However most
databases achieve a sort of `steady state' (roughly the same number of
records being added and deleted regularly) and plain vacuum suffices
for that.  Transactions are possible during vacuum, and most
installations will prefer to use that periodically over vacuum full.
It's only if your database sizes vary wildly over the course of time
that you'll need to use vacuum full (and consequently bring the system
down for maintenance).

The above is from my understanding of PgSQL, would appreciate
clarifications in case I've missed anything out.

Ambar Another intresting thing about postgresql is that while the
Ambar web hosting control panels on Linux used to only support
Ambar MySQL, cPanel  Plesk now have support for Postgresql. To
Ambar me this is a good sign. Now even smaller sites can start
Ambar using Postgresql.

Regards,

- -- Raju
- -- 
Raj Mathur[EMAIL PROTECTED]  http://kandalaya.org/
   GPG: 78D4 FC67 367F 40E2 0DD5  0FEF C968 D0EF CC68 D17F
  It is the mind that moves
-BEGIN PGP SIGNATURE-
Version: GnuPG v1.0.7 (GNU/Linux)
Comment: Processed by Mailcrypt 3.5.6 and Gnu Privacy Guard http://www.gnupg.org/

iD8DBQE/joo+yWjQ78xo0X8RAh/9AJ92FPCIhsOSYWwlOrgI610XI6IjtQCbBOCv
apkVPv4S87Ot14c7+YDzGwo=
=RF8Y
-END PGP SIGNATURE-

___
ilugd mailing list
[EMAIL PROTECTED]
http://frodo.hserus.net/mailman/listinfo/ilugd


RE: [ilugd] Postgres vs oracle

2003-10-15 Thread Tarun Dua
On Tue, 2003-10-14 at 19:58, Gurpreet Singh Sachdeva wrote:
 Hi Tarun,
Let me make it very cleat that I don't have any hunch in open source 
 and thats why I am in the list but my dear, facts are facts.
 (Is Amazon.com running on open source (database)? Is eBay.com running on open source 
 (database)? Is Yahoo.com running on open source (database)?
Citing now,
http://www.serverworldmagazine.com/sunserver/2001/02/bigboys.shtml
http://www.mysql.com/press/user_stories/yahoo_finance.html
http://www.ziatg.com/Content/success_stories.htm


 Surely NO...so we would certainly be interested to know some of your  Biggest 
 Internet Sites running on open source.

Geocrawler use Postgres.

http://sourceforge.net/docman/display_doc.php?docid=755group_id=1
Quote
PostgreSQL has proven itself a stable and strong-performing database
solution. PostgreSQL is the database back used to power the
SourceForge.net site today.
/Quote

sf.net uses mysql
And some of the biggest sites are the Open Source community's sites
running on Open Source databases.
 Kindly show us any relevant benchmark to prove your point on your tried and tested 
 approach. 
See
http://formation.espacecourbe.com/choosing/dbc_paper_opensource_database.html
 And also do let us know if we can live without Foreign Keys in a relational world 
 (MySQL)? 
All that is history!! Check out the newer InnoDb support.

-Tarun Dua


___
ilugd mailing list
[EMAIL PROTECTED]
http://frodo.hserus.net/mailman/listinfo/ilugd


RE: [ilugd] Postgres vs oracle

2003-10-15 Thread supreet
I do'nt know for sure but as far as my memory goes.

sf.net started of with postgres and then moved on to use DB2 from IBM
because of scaling issues with postgres.
-- 
supreet [EMAIL PROTECTED]


___
ilugd mailing list
[EMAIL PROTECTED]
http://frodo.hserus.net/mailman/listinfo/ilugd


RE: [ilugd] Postgres vs oracle

2003-10-14 Thread Gurpreet Singh Sachdeva
Hi Tarun,
   Let me make it very cleat that I don't have any hunch in open source 
and thats why I am in the list but my dear, facts are facts.
(Is Amazon.com running on open source (database)? Is eBay.com running on open source 
(database)? Is Yahoo.com running on open source (database)?
Surely NO...so we would certainly be interested to know some of your  Biggest 
Internet Sites running on open source.
Kindly show us any relevant benchmark to prove your point on your tried and tested 
approach. That (deploying parallel servers) reminds me of a circus.
Parallel execution of query in PostgeSQL? Try out and f'd for yourself. And also do 
let us know if we can live without Foreign Keys in a relational world (MySQL)? 
Well I would prefer (anyday) a muft thandi lassi than a muft thanda software.
Regards,
Gurpreet Singh Sachdeva

-Original Message- 
From: Tarun Dua [mailto:[EMAIL PROTECTED] 
Sent: Tue 10/14/2003 2:16 PM 
To: The Linux-Delhi mailing list 
Cc: 
Subject: RE: [ilugd] Postgres vs oracle



On Mon, 2003-10-13 at 22:13, Gurpreet Singh Sachdeva wrote:
 The strategy of employing dual servers to divide your data
 is a short term arrangement. Lot of performance related issues *will* crop 
up in the future and lot of fingers would be raised on you.
No such things would happen if the architecture is good.
If at all this would normally lead to performance improvement not
degradation.
The strategy to divide the Database onto multiple parallel servers is a good 
one
And a tried and tested one at that.
It would be anyday faster than a single large footprint database
cluster.
All you would need to do is pick up data in parallel from more than one
database to generate a report and very likely use a single database for
a transaction.
And Gurpreet about your hunch on using a Free Software.
Biggest of Internet Sites are running on open source databases.
And you have option of paying up if you don't like Free(muft as in
thandi lassi) software.

-Tarun




___
ilugd mailing list
[EMAIL PROTECTED]
http://frodo.hserus.net/mailman/listinfo/ilugd



___
ilugd mailing list
[EMAIL PROTECTED]
http://frodo.hserus.net/mailman/listinfo/ilugd


RE: [ilugd] Postgres vs oracle

2003-10-14 Thread Raj Mathur

Gurpreet 
SGkgVGFydW4sDQogICAgICAgICAgICAgICBMZXQgbWUgbWFrZSBpdCB2ZXJ5IGNsZWF0IHRoYXQg
Gurpreet 
SSBkb24ndCBoYXZlIGFueSBodW5jaCBpbiBvcGVuIHNvdXJjZSBhbmQgdGhhdHMgd2h5IEkgYW0g
Gurpreet 
aW4gdGhlIGxpc3QgYnV0IG15IGRlYXIsIGZhY3RzIGFyZSBmYWN0cy4NCihJcyBBbWF6b24uY29t
Gurpreet 
IHJ1bm5pbmcgb24gb3BlbiBzb3VyY2UgKGRhdGFiYXNlKT8gSXMgZUJheS5jb20gcnVubmluZyBv
Gurpreet 
biBvcGVuIHNvdXJjZSAoZGF0YWJhc2UpPyBJcyBZYWhvby5jb20gcnVubmluZyBvbiBvcGVuIHNv
Gurpreet 
dXJjZSAoZGF0YWJhc2UpPw0KU3VyZWx5IE5PLi4uc28gd2Ugd291bGQgY2VydGFpbmx5IGJlIGlu
Gurpreet 
dGVyZXN0ZWQgdG8ga25vdyBzb21lIG9mIHlvdXIgPiAiQmlnZ2VzdCBJbnRlcm5ldCBTaXRlcyBy
Gurpreet 
dW5uaW5nIG9uIG9wZW4gc291cmNlIi4NCktpbmRseSBzaG93IHVzIGFueSByZWxldmFudCBiZW5j
Gurpreet 
aG1hcmsgdG8gcHJvdmUgeW91ciBwb2ludCBvbiB5b3VyICJ0cmllZCBhbmQgdGVzdGVkIGFwcHJv
Gurpreet 
YWNoIi4gVGhhdCAoZGVwbG95aW5nIHBhcmFsbGVsIHNlcnZlcnMpIHJlbWluZHMgbWUgb2YgYSBj
Gurpreet 
aXJjdXMuDQpQYXJhbGxlbCBleGVjdXRpb24gb2YgcXVlcnkgaW4gUG9zdGdlU1FMPyBUcnkgb3V0
Gurpreet 
IGFuZCBmJ2QgZm9yIHlvdXJzZWxmLiBBbmQgYWxzbyBkbyBsZXQgdXMga25vdyBpZiB3ZSBjYW4g
Gurpreet 
bGl2ZSB3aXRob3V0IEZvcmVpZ24gS2V5cyBpbiBhIHJlbGF0aW9uYWwgd29ybGQgKE15U1FMKT8g
Gurpreet 
DQpXZWxsIEkgd291bGQgcHJlZmVyIChhbnlkYXkpIGEgbXVmdCB0aGFuZGkgbGFzc2kgdGhhbiBh
Gurpreet 
IG11ZnQgInRoYW5kYSIgc29mdHdhcmUuDQpSZWdhcmRzLA0KR3VycHJlZXQgU2luZ2ggU2FjaGRl
Gurpreet 
dmENCg0KCS0tLS0tT3JpZ2luYWwgTWVzc2FnZS0tLS0tIA0KCUZyb206IFRhcnVuIER1YSBbbWFp
Gurpreet 
bHRvOnRhcnVuZHVhQGxpbnV4LWRlbGhpLm9yZ10gDQoJU2VudDogVHVlIDEwLzE0LzIwMDMgMjox
Gurpreet 
NiBQTSANCglUbzogVGhlIExpbnV4LURlbGhpIG1haWxpbmcgbGlzdCANCglDYzogDQoJU3ViamVj
Gurpreet 
dDogUkU6IFtpbHVnZF0gUG9zdGdyZXMgdnMgb3JhY2xlDQoJDQoJDQoNCglPbiBNb24sIDIwMDMt
Gurpreet 
MTAtMTMgYXQgMjI6MTMsIEd1cnByZWV0IFNpbmdoIFNhY2hkZXZhIHdyb3RlOg0KCT4gVGhlIHN0
Gurpreet 
cmF0ZWd5IG9mIGVtcGxveWluZyBkdWFsIHNlcnZlcnMgdG8gZGl2aWRlIHlvdXIgZGF0YQ0KCT4g
Gurpreet 
aXMgYSBzaG9ydCB0ZXJtIGFycmFuZ2VtZW50LiBMb3Qgb2YgcGVyZm9ybWFuY2UgcmVsYXRlZCBp
Gurpreet 
c3N1ZXMgKndpbGwqIGNyb3AgdXAgaW4gdGhlIGZ1dHVyZSBhbmQgbG90IG9mIGZpbmdlcnMgd291
Gurpreet 
bGQgYmUgcmFpc2VkIG9uIHlvdS4NCglObyBzdWNoIHRoaW5ncyB3b3VsZCBoYXBwZW4gaWYgdGhl
Gurpreet 
IGFyY2hpdGVjdHVyZSBpcyBnb29kLg0KCUlmIGF0IGFsbCB0aGlzIHdvdWxkIG5vcm1hbGx5IGxl
Gurpreet 
YWQgdG8gcGVyZm9ybWFuY2UgaW1wcm92ZW1lbnQgbm90DQoJZGVncmFkYXRpb24uDQoJVGhlIHN0
Gurpreet 
cmF0ZWd5IHRvIGRpdmlkZSB0aGUgRGF0YWJhc2Ugb250byBtdWx0aXBsZSBwYXJhbGxlbCBzZXJ2
Gurpreet 
ZXJzIGlzIGEgZ29vZCBvbmUNCglBbmQgYSB0cmllZCBhbmQgdGVzdGVkIG9uZSBhdCB0aGF0Lg0K
Gurpreet 
CUl0IHdvdWxkIGJlIGFueWRheSBmYXN0ZXIgdGhhbiBhIHNpbmdsZSBsYXJnZSBmb290cHJpbnQg
Gurpreet 
ZGF0YWJhc2UNCgljbHVzdGVyLg0KCUFsbCB5b3Ugd291bGQgbmVlZCB0byBkbyBpcyBwaWNrIHVw
Gurpreet 
IGRhdGEgaW4gcGFyYWxsZWwgZnJvbSBtb3JlIHRoYW4gb25lDQoJZGF0YWJhc2UgdG8gZ2VuZXJh
Gurpreet 
dGUgYSByZXBvcnQgYW5kIHZlcnkgbGlrZWx5IHVzZSBhIHNpbmdsZSBkYXRhYmFzZSBmb3INCglh
Gurpreet 
IHRyYW5zYWN0aW9uLg0KCUFuZCBHdXJwcmVldCBhYm91dCB5b3VyIGh1bmNoIG9uIHVzaW5nIGEg
Gurpreet 
RnJlZSBTb2Z0d2FyZS4NCglCaWdnZXN0IG9mIEludGVybmV0IFNpdGVzIGFyZSBydW5uaW5nIG9u
Gurpreet 
IG9wZW4gc291cmNlIGRhdGFiYXNlcy4NCglBbmQgeW91IGhhdmUgb3B0aW9uIG9mIHBheWluZyB1
Gurpreet 
cCBpZiB5b3UgZG9uJ3QgbGlrZSBGcmVlKG11ZnQgYXMgaW4NCgl0aGFuZGkgbGFzc2kpIHNvZnR3
Gurpreet 
YXJlLg0KCQ0KCS1UYXJ1bg0KCQ0KCQ0KCQ0KCQ0KCV9fX19fX19fX19fX19fX19fX19fX19fX19f
Gurpreet 
X19fX19fX19fX19fX19fX19fX19fDQoJaWx1Z2QgbWFpbGluZyBsaXN0DQoJaWx1Z2RAbGlzdHMu
Gurpreet 
bGludXgtZGVsaGkub3JnDQoJaHR0cDovL2Zyb2RvLmhzZXJ1cy5uZXQvbWFpbG1hbi9saXN0aW5m
Gurpreet by9pbHVnZA0KCQ0KCQ0KDQo=

Any particular reason you're writing in base64 as opposed to, say,
quoted-printable or text/plain?

-- Raju
-- 
Raj Mathur[EMAIL PROTECTED]  http://kandalaya.org/
   GPG: 78D4 FC67 367F 40E2 0DD5  0FEF C968 D0EF CC68 D17F
  It is the mind that moves

___
ilugd mailing list
[EMAIL PROTECTED]
http://frodo.hserus.net/mailman/listinfo/ilugd


RE: [ilugd] Postgres vs oracle

2003-10-13 Thread Gurpreet Singh Sachdeva
Dear Tarun,
Comparison of PostgreSQL (open source) vis-a-vis Oracle (commercial) is UNFAIR! The 
subject *should* be PostgeSQL vs Foxpro Ooops  MySQL. PostgreSQL no doubt is a good 
database BUT you can't match Oracle's superior technology. Its in the business for the 
past 27 years (PostgreSQL made its presence felt in 1996) and a dominant player (40% 
market share). 
 
Oracle's database is supported on PDAs to MPP machines (support for more than 200 
platforms). PostgreSQL CAN't boast such kind of statistics.
 
Replication Support was ONLY announced lately  28/08/2003. It will take *some* time 
to mature (bug fixing underway).
 
Fail over support  Yawn, Yawn ...N/D (No Details). Oracle's technology (i.e Real 
Application Clusters) *is* UNBREAKABLE.
 
Consider this:
 
Synonyms
Postgres: No
 
Updateable views
Postgres:  No.  
 
Partial rollback of transaction
Postgres:  No. 
 
Practically useful maximum number of concurrent users
Postgres:  N/D 
 
Practical maximum number of concurrent users writing to the database
Postgres:  N/D 
 
Incremental backups
Postgres:  No. 
 
Scalability - Support for SMP systems (parallel query execution, etc.)
Postgres:  Postgres is not threaded, but every connection gets it's own process. The 
OS will distribute the processes across the processors. Basically a single connection 
will not be any faster with SMP, but multiple connections will be.  
 
Bitmap indexes
Postgres:  No. 
 
OLAP supporting functions in SQL
Postgres:  No. 
 
Automatic partitioning of large tables/indexes
Postgres:  No. 
 
Gateways to other DBMSs
Postgres:  None. 
 
Access to multiple databases in one session
Postgres:  Only switching between databases.  
 
Two phase commit
Postgres:  No. 
 
VLDB implementations
Postgres:  60GB+ databases exist BUT performance usually degrades.
 
Support from CASE packages
Postgres:  N/D 
 
Special solutions for storage of XML documents
Postgres:  No. 
 
XML support integrated in DBMS
Postgres:  No. 
 
Dedicated Web servers
Postgres:  None. 
 
Automatic recovery from failures
Postgres:  No. There is no transaction log, so the only recovery method is to restore 
database from backup 
 
Availability and quality of technical support
Postgres:  ONLY mailing lists and web-site (postgresql.org). Poor.  
 
Specific market segments occupied
Postgres:  Mostly in education and small web services

-Original Message- 
From: Tarun Upadhyay [mailto:[EMAIL PROTECTED] 
Sent: Fri 10/10/2003 9:50 PM 
To: 'The Linux-Delhi mailing list' 
Cc: 
Subject: [ilugd] Postgres vs oracle



We have a customer application on oracle.

They want to crate a small footprint version of it to be sold at a cheaper
price.

I want to suggest that Postgres could be the right choice of database for
that as it is close to oracle in its sql syntax and hence porting should be
simpler.

Can anybody guide me on what kind of pitfalls we could run into by choosing
Postgres. The database is not very large but is much larger than what goes
for database in mysql discussions (about 1 GB of data, 100 tables with
about 10-50 MB added every day)?

In particular, I would be interested in hearing from people who have run
moderately large databases on postgres and how fast they found it.

I have heard that it is possible to now provide replication and fail over
with postgres. Has anybody tried it?

Tarun


___
ilugd mailing list
[EMAIL PROTECTED]
http://frodo.hserus.net/mailman/listinfo/ilugd



___
ilugd mailing list
[EMAIL PROTECTED]
http://frodo.hserus.net/mailman/listinfo/ilugd


[ilugd] Postgres vs oracle

2003-10-10 Thread Tarun Upadhyay
We have a customer application on oracle.

They want to crate a small footprint version of it to be sold at a cheaper
price.

I want to suggest that Postgres could be the right choice of database for
that as it is close to oracle in its sql syntax and hence porting should be
simpler.

Can anybody guide me on what kind of pitfalls we could run into by choosing
Postgres. The database is not very large but is much larger than what goes
for database in mysql discussions (about 1 GB of data, 100 tables with
about 10-50 MB added every day)?

In particular, I would be interested in hearing from people who have run
moderately large databases on postgres and how fast they found it.

I have heard that it is possible to now provide replication and fail over
with postgres. Has anybody tried it?

Tarun


___
ilugd mailing list
[EMAIL PROTECTED]
http://frodo.hserus.net/mailman/listinfo/ilugd


RE: [ilugd] Postgres vs oracle

2003-10-10 Thread Gurpreet Singh Sachdeva
Hi Tarun,
  I think you are trying to compare a Apple with a Water Melon. But any 
case if you are really facing a real time scenario, please make it clear. what exactly 
the application you are running and how many concurrent user you are expecting to be 
there as concurrency is a major factor which can cause ample amount of problems for 
the DBA. I make sure that I would be able to solve all your queries.
Regards,
Gurpreet Singh Sachdeva
 

-Original Message- 
From: Tarun Upadhyay [mailto:[EMAIL PROTECTED] 
Sent: Fri 10/10/2003 9:50 PM 
To: 'The Linux-Delhi mailing list' 
Cc: 
Subject: [ilugd] Postgres vs oracle



We have a customer application on oracle.

They want to crate a small footprint version of it to be sold at a cheaper
price.

I want to suggest that Postgres could be the right choice of database for
that as it is close to oracle in its sql syntax and hence porting should be
simpler.

Can anybody guide me on what kind of pitfalls we could run into by choosing
Postgres. The database is not very large but is much larger than what goes
for database in mysql discussions (about 1 GB of data, 100 tables with
about 10-50 MB added every day)?

In particular, I would be interested in hearing from people who have run
moderately large databases on postgres and how fast they found it.

I have heard that it is possible to now provide replication and fail over
with postgres. Has anybody tried it?

Tarun


___
ilugd mailing list
[EMAIL PROTECTED]
http://frodo.hserus.net/mailman/listinfo/ilugd



___
ilugd mailing list
[EMAIL PROTECTED]
http://frodo.hserus.net/mailman/listinfo/ilugd


RE: [ilugd] Postgres vs oracle

2003-10-10 Thread Tarun Upadhyay
Gupreet,
It is a real application. It's an OLTP appliaction for banking and
credit card industry. From a concurrency point of view, I expect about 200
connections to the database in the worst case and a fifth of that on the
average.
however, if postgres cannot handle that kind of user connections;
that is fine too. I just need to know the number it can handle and then I
will find a way of dividing the data over 2 or more servers such that each
gets lesser load.

A little off-topic, but
A little research on the web mentions that Postgres Query optimizer
is weak and in general one should optimize the queries by hand (we have to
do the same for oracle anyway. For that kind of database size, I do not
trust the query optimizer any way). Is that true?

-Original Message-
From: [EMAIL PROTECTED]
[mailto:[EMAIL PROTECTED] On
Behalf Of Gurpreet Singh Sachdeva
Sent: Saturday, October 11, 2003 2:32 AM
To: The Linux-Delhi mailing list; The Linux-Delhi mailing list
Subject: RE: [ilugd] Postgres vs oracle


Hi Tarun,
  I think you are trying to compare a Apple with a Water Melon.
But any case if you are really facing a real time scenario, please make it
clear. what exactly the application you are running and how many concurrent
user you are expecting to be there as concurrency is a major factor which
can cause ample amount of problems for the DBA. I make sure that I would be
able to solve all your queries. Regards, Gurpreet Singh Sachdeva
 

-Original Message- 
From: Tarun Upadhyay [mailto:[EMAIL PROTECTED] 
Sent: Fri 10/10/2003 9:50 PM 
To: 'The Linux-Delhi mailing list' 
Cc: 
Subject: [ilugd] Postgres vs oracle



We have a customer application on oracle.

They want to crate a small footprint version of it to be sold at a
cheaper
price.

I want to suggest that Postgres could be the right choice of
database for
that as it is close to oracle in its sql syntax and hence porting
should be
simpler.

Can anybody guide me on what kind of pitfalls we could run into by
choosing
Postgres. The database is not very large but is much larger than
what goes
for database in mysql discussions (about 1 GB of data, 100 tables
with
about 10-50 MB added every day)?

In particular, I would be interested in hearing from people who have
run
moderately large databases on postgres and how fast they found it.

I have heard that it is possible to now provide replication and fail
over
with postgres. Has anybody tried it?

Tarun


___
ilugd mailing list
[EMAIL PROTECTED]
http://frodo.hserus.net/mailman/listinfo/ilugd





___
ilugd mailing list
[EMAIL PROTECTED]
http://frodo.hserus.net/mailman/listinfo/ilugd