PostgreSQL 8.2 er sluppet

[Frank2004]

http://www.postgresql.org/docs/current/sta...elease-8-2.html

 

Løp og kjøp!

 

Edit: kom over en litt penere side med release notes.

Endret 6. desember 2006 av Frank2004

[roac]

Takker, herved nedlastet. Må prøves ut.

[endrebjo]

Løp og kjøp!

7440388[/snapback]

[kaffenils]

Løp og kjøp!

7440388[/snapback]

7448293[/snapback]

 

Hørt om ordspill?

[siDDis]

Trur eg enda venter med å oppgradere min 8.1 enda. Det er ikkje dei altfor store forandringane for min bruk enda

 

Kom nettopp over eit ganske nytt og ferskt test av PGSQL og MySQL

http://tweakers.net/reviews/657

 

Denne er testa på read/write system som er noko anna enn bare eit read system.

 

Så var det og idag posta ein anna samanlikning på Slashdot(som visstnok var 2 år gammal) Og der får MySQL skikkeleg mykje drittslenging i kommentarene.

http://developers.slashdot.org/article.pl?...6/12/18/1152230

 

The client library is GPL. That means you cannot create a commercial program that uses it without using the commercial licensed version. Which is $200 per client

 

You can't even create a library and not ship mysql - the mysql site is very clear that they consider distributing a program that *uses* mysql as being exactly the same as distributing mysql itself:

 

http://www.mysql.com/company/legal/licensing/comme rcial-license.html [mysql.com]

 

Typical examples of MySQL distribution include: ...

        * Selling software that requires customers to install MySQL themselves on their own machines.

 

Specifically:

 

        * If you develop and distribute a commercial application and as part of utilizing your application, the end-user must download a copy of MySQL; for each derivative work, you (or, in some cases, your end-user) need a commercial license for the MySQL server and/or MySQL client libraries.

 

This makes mysql unusable for anything except large products. Our entire product only cost $70 for the single user version. No way in hell we're upping the price by $200 a copy.

 

Emphasis mine. In other words, You don't have to pay the $200 if your project is itself compliant with the GPL or similar license scheme.

 

"Comply with the GPL or pay us $200 to legally use our code or libraries" is not the same as saying "You have to pay us $200 if you plan to sell software you made using our code or libraries."

 

Foreign keys are more than nice, they are essential.

Bingo!

 

It doesn't cease to amaze me, when the Mysql croud argues that "you don't really need those pesky integrity stuff, it just slows down the database."

 

Guess what guys; You're dead wrong!

 

Any DBA worth his salary will enforce data integrity on the lowest possible level, which means constraints (however implemented) on the object level.

 

Sure, you can let your coders in Bengaluru ensure that the primary key is unique instead of just applying a unique index and the same goes for referential constraints between tables. You can implement them in the application just fine until somebody overlooks some minor detail in the code and you're royally fucked!

 

Again! Foreign keys or triggers are not "niceties". They are essential in implementing an industry strength database; period!

 

In my job, we moved from mysql to postgres several years ago (around PG 7.0). At the time, we needed to make the move for performance reasons. We are in a read-write system, and MySQL's locking was killing us (this was before InnoDB was well established). The features are better too, as our developers were used to having data integrity features, server side programming, and all of the SQL92 constructs available. We also learned a bit about PG performance, which I'll share.

 

1) Run EXPLAIN ANALYZE on everything. Postgresql is touchier about query performance than MySQL was. This just needs to be a habit if you're using PG. (You really should do performance analysis no matter your DB. It's just a good practice). The biggest gain will be making sure you're using index scans rather than sequential scans.

 

2) Use persistent connections. Everyone likes to point out the forking issue with PG vs. MySQL's threaded. PG's connection handling is slow, there's no doubt about it. But there's an easy answer. Just limit how often you connect. If you can keep a connection pool, and just reuse those connections, you'll save this big hit.

 

3) Full vacuum and reindex regularly. We've found the docs to be a bit off on this. It indicates that you should run these occasionally. If you're in a read-write system, a full vacuum on a regular basis is very important. It really doesn't take that long if you do it regularly. Also, we've had trouble with indexes getting unbalanced (we see 50->90% tuple turnover daily). This has gotten better, but it doesn't hurt to let your maintenance scripts make things ideal for you. So, we run a full vacuum and reindex of our tables nightly through cron.

 

4) Get your shared memory right. PG's shared buffers is probably the most important config attribute. It controls how much of your DB is memory resident vs disk resident. Avoiding disk hits is a big deal for any DB, so get this right. If you can fit your whole DB in memory, then do it. If not, make sure your primary tables will fit. The more you use the shared memory, and the less you have to page data in/out, the better your overall performance will be.

 

Most DB systems seem to be read-mostly, so I can understand the performance comparisons focusing on that. In our read-write system though, the locking was the biggest issue and it tilted the performance comparison toward PG.

 

 

Det som er kanskje litt merkeleg for nokon er at det er nesten ingen som forsvarer MySQL, det beste eg fant var dette

 

You have to give the MySQL guys credit for the fact that it is an incredibly easy product when it comes to configuring it for your needs. For me, out of college, going to Oracle was a culture shock because the process of configuring Oracle was so convoluted and drawn out for simple stuff. I know that Oracle and PostgreSQL can be much more powerful than MySQL, but there is something to be said for how easy it is for a developer to install MySQL and just start working with it.

 

Noko som eg ikkje kan sei meg heilt einig i. Synes det er minst like lett å koma i gong med PostgreSQL

[roac]

Foreign keys are more than nice, they are essential.

Bingo!

 

It doesn't cease to amaze me, when the Mysql croud argues that "you don't really need those pesky integrity stuff, it just slows down the database."

 

Guess what guys; You're dead wrong!

 

Any DBA worth his salary will enforce data integrity on the lowest possible level, which means constraints (however implemented) on the object level.

 

Sure, you can let your coders in Bengaluru ensure that the primary key is unique instead of just applying a unique index and the same goes for referential constraints between tables. You can implement them in the application just fine until somebody overlooks some minor detail in the code and you're royally fucked!

 

Again! Foreign keys or triggers are not "niceties". They are essential in implementing an industry strength database; period!

7532365[/snapback]

Vel, det blir galt å forsvare her, uansett hvem du forsvarer. Det er ikke alltid du trenger referanseintegritet. Det er ikke alltid du trenger triggere. Triggere bør sågar med fordel holdes på et minimum, rett og slett av ytelseshensyn. Andre typer constraints kan man også klare seg uten. Det kommer rett og slett an på bruken.

 

For tiden skulle jeg faktisk ønske at jeg kunne opprette databaser i MSSQL uten støtte for referanseintegritet og triggere, men det lar seg dessverre ikke gjøre. Dette til tross for at løsningen det gjelder inneholder en rekke tabeller. Jeg har rett og slett ikke bruk for funksjonaliteten.

 

Man må innse det gode gamle prinsippet: Hvert til sitt bruk. MySQL har sine bruksområder, PostgreSQL har sine, og det samme gjelder for DB2, Sybase, Oracle og MSSQL. At MySQL har lett for å "komme dårligst ut" blant disse skal jeg ikke si noe på, men det betyr ikke at MySQL er noe i retning av ubrukelig på grunn av mangel på funksjonalitet, snarere tvert om. Den er svært så anvendelig til sine ting.

[siDDis]

Eg kan ikkje sjå ein einaste grunn til kvifor ein skal bruke MySQL, trenger ein noko raskt og enkelt til f.eks ein webside så kan ein bruke SQLite.

 

SQLite er MYKJE raskare enn MySQL når det kjem til lesing av data. Den er og fullt brukbar om dataintegritet er ein viktig faktor!! Og ikkje minst den er Public Domain! SQLite har sine mangler http://www.sqlite.org/omitted.html og når SQLite skulle bli for kort så blir MySQL kanskje eit alternativ. Men 99.99% av alle websider så duger SQLite heilt flott! MySQL er som Windows brukere, alle bruker det og derfor er det best.

 

La oss ta ein enkel select test: http://www.whenpenguinsattack.com/2006/03/...se-speed-tests/

SQLite 3.3.3 (sync):

1.883

SQLite 3.3.3 (nosync):

1.894

SQLite 2.8.17 (sync):

1.994

SQLite 2.8.17 (nosync):

1.973

PostgreSQL 8.1.2:

23.933

MySQL 5.0.18 (sync):

16.348

MySQL 5.0.18 (nosync):

17.383

FirebirdSQL 1.5.2:

15.542

Som den viser så lenge det er 99.999999% med bare lesing og indeks er laga så er SQLite eit kjempeflott alternativ for enkle websider.

Så kva er MySQL best til? Ikkje kan eg svare på det med mitt kunnskapsnivå men eg er overbevist om at minst 99% av MySQL brukerane bruker ein database dei *trur* er best for sitt bruk utan å ha kikka på alternativer. Faktisk så trur eg diskusjon.no hadde kjørt raskare med SQLite istadenfor MySQL. Men det kjem vell mykje ann på dette:

Situations Where Another RDBMS May Work Better

 

Client/Server Applications

 

 

If you have many client programs accessing a common database over a network, you should consider using a client/server database engine instead of SQLite. SQLite will work over a network filesystem, but because of the latency associated with most network filesystems, performance will not be great. Also, the file locking logic of many network filesystems implementation contains bugs (on both Unix and windows). If file locking does not work like it should, it might be possible for two or more client programs to modify the same part of the same database at the same time, resulting in database corruption. Because this problem results from bugs in the underlying filesystem implementation, there is nothing SQLite can do to prevent it.

 

A good rule of thumb is that you should avoid using SQLite in situations where the same database will be accessed simultaneously from many computers over a network filesystem.

 

High-volume Websites

 

SQLite will normally work fine as the database backend to a website. But if you website is so busy that your are thinking of splitting the database component off onto a separate machine, then you should definitely consider using an enterprise-class client/server database engine instead of SQLite.

 

Very large datasets

 

When you start a transaction in SQLite (which happens automatically before any write operation that is not within an explicit BEGIN...COMMIT) the engine has to allocate a bitmap of dirty pages in the disk file to help it manage its rollback journal. SQLite needs 256 bytes of RAM for every 1MB of database. For smaller databases, the amount of memory required is not a problem, but when database begin to grow into the multi-gigabyte range, the size of the bitmap can get quite large. If you need to store and modify more than a few dozen GB of data, you should consider using a different database engine.

 

High Concurrency

 

SQLite uses reader/writer locks on the entire database file. That means if any process is reading from any part of the database, all other processes are prevented from writing any other part of the database. Similarly, if any one process is writing to the database, all other processes are prevented from reading any other part of the database. For many situations, this is not a problem. Each application does its database work quickly and moves on, and no lock lasts for more than a few dozen milliseconds. But there are some applications that require more concurrency, and those applications may need to seek a different solution.

 

Uff her går det off-topic, får vell dra det over i ein anna tråd

[roac]

Men 99.99% av alle websider så duger SQLite heilt flott! MySQL er som Windows brukere, alle bruker det og derfor er det best.

7533058[/snapback]

Problemet med Linuxbrukere er at de tror brukere er en homogen masse med samme interesser og behov som dem selv