[MySQL] Postgre functie wil niet in MySQL

[Verwijderd]

Misschien een hele stomme vraag maar ik heb de volgende functie ooit in PostgreSQL gebruikt, hoe kan ik deze eventueel in mysql gebruiken?

code:

CREATE FUNCTION "restxt" (integer,integer) RETURNS character varying AS 'SELECT value FROM resources WHERE rid = $1 AND language = $2;' LANGUAGE 'sql';

Ik heb al door de handleiding gebladerd maar kan er echt niet uitkomen.

thanks!

[ACM]

Op maandag 24 juni 2002 14:47 schreef gizmonl het volgende:
Ik heb al door de handleiding gebladerd maar kan er echt niet uitkomen.

Je had niet gezien dat mysql nauwelijks support voor functions kent?

Oftewel, antwoord is: niet

Als je dit soort krachtige dingen wilt moet je niet aan mysql beginnen.

[Verwijderd]

Ik wist idd dat het maar beperkt kon, vandaag dat ik me gewoon af vroeg of dit kon.

MySQL is veel sneller gebleken als Postgre, vandaar de overstap.

Maar das mooi muts dat het niet kan

[ACM]

Op maandag 24 juni 2002 15:01 schreef gizmonl het volgende:
MySQL is veel sneller gebleken als Postgre, vandaar de overstap.

Mysql is alleen met lichte en simpele dingen sneller.
Zware queries gaan in postgres sneller of even snel.
Ook schijnt de schaling van postgres nog beter te zijn.

Daarnaast heeft postgres default een veeel veiliger opslag formaat dan mysql (transactie support, veilige opslag oa door garantie dat de data op disk altijd consistent is, triggers, foreign keys etc), daar tegenover heeft mysql tegenwoordig innodb, maar dat mist nog steeds een hoop.

Het argument 'mysql is sneller' is een van de slechtste imho om over te stappen. Vooral omdat 'sneller' altijd maar relatief is.

[Verwijderd]

Nou het gaat in dit geval over miljoenen hits van een statistieken programma.

Dat tijdsverschil van een querry is nu wel zo groot dan we "gedwongen" zijn om MySQL te gebruiken, het is zelfs zo dat we timeouts gaan krijgen met postgre.....

[ACM]

Mja.

Heb je dan de standaard postgres-tuning-trucjes al uitgehaald?
De buffers vergroot, na veel inserts 'vacuum analyze' en af en toe 'vacuum analyze full' of zelfs 'vacuum analyze full freeze', de indices op de goede plekken gelegd (explain analyze query...), de queries handig opgezet etc?

Want ik kan me niet zo goed voorstellen dat postgres zo veel langer dan mysql er over doet.

Vooral de korte queries duren relatief veel langer, maar als een query flink wat rekenwerk kost loopt postgres aardig in.

En je hebt wel versie 7.2.1 dan he?

[Verwijderd]

Nope, versie is 7.1.3 .....

Het is idd een tijdje terug dat we de test hebben gedaan, maar het verschil was zo dusdanig groot dat we meteen zwaar overtuigd waren.

Hmmm zit nu zwaar te denken of we het niet nog een keer moeten testen......

Ik laat het ff bezinken, thanks voor je uitleg!

Ik weet iig wel dat als ik de functie niet kan gebruiken ik waarschijnlijk uiteindelijk net zoveel tijd kwijt ben om de complete query te doen......

[ACM]

Op maandag 24 juni 2002 15:39 schreef gizmonl het volgende:
Nope, versie is 7.1.3 .....

Upgraden is iig zeker aan te raden, de performance was verbeterd en de vacuum-werking zodanig aangepast dat er nauwelijks locking voor nodig is.

Het is idd een tijdje terug dat we de test hebben gedaan, maar het verschil was zo dusdanig groot dat we meteen zwaar overtuigd waren.

De kans is wel groot dat mysql nog steeds sneller is, maar ik vind het wel raar dat het zoveel sneller is

Hmmm zit nu zwaar te denken of we het niet nog een keer moeten testen......

Lijkt me verstandig, soms vindt de query-analyzer van postgres trouwens ook dat een query via een bepaalde methode moet worden uitgevoerd terwijl dat niks sneller is of zelfs veel trager (ik had iets dat van 17ms naar 350ms oid ging... alleen maar omdat er 1 result meer uit de query kwam ) dat , daarvoor is het het handigst als je de queries die je uitvoert inclusief executietijd en explain (analyze) resultaten afdrukt.

Daaraan kan je dan zien hoe en wat, mijn probleempje was te verhelpen door 'SET ENABLE_MERGEJOIN=OFF' te roepen naar de backend
(ja, is een vrij vieze oplossing, maar scheelde wel een factor 20 op de querytijd)

Ik laat het ff bezinken, thanks voor je uitleg!

Np, vraag gerust meer

Ik weet iig wel dat als ik de functie niet kan gebruiken ik waarschijnlijk uiteindelijk net zoveel tijd kwijt ben om de complete query te doen......

Dat is sowieso weer een nadeel idd.

[Verwijderd]

Ik ga het morgen even testen en zal de results hier posten.

MySql 4 schijnt wel die functie aan te kunnen, maar dat is nog een te groot risico volgens mij.

Het upgraden zal niet lukken omdat de server een te zware productie draait, die kan niet plat

Maar ik zal een andere server tijdelijk tot Postgre en MySql database benoemen. Daar even de database op overpompen, en dan even op zn flikker geven.

[ACM]

Op maandag 24 juni 2002 16:03 schreef gizmonl het volgende:
Het upgraden zal niet lukken omdat de server een te zware productie draait, die kan niet plat

Voor de overstap naar mysql moet ie toch ook plat, dus kan je beter de boel eerst goed getest hebben enzo

[Verwijderd]

Jep dat klopt, maar dat gaat om 3 uur snachts gebeuren.

En dat was ik niet van plan om al te vaak te doen

[dusty]

Op maandag 24 juni 2002 14:58 schreef ACM het volgende:
[..]
Als je dit soort krachtige dingen wilt moet je niet aan mysql beginnen.

Als je dit soort iets krachtige dingens wilt doen moet je niet aan mysql beginnen.

[Verwijderd]

Ik heb een oplossing gevonden die in ongeveer hetzelfde doet, het vergt af en toe een kwerrie extra en het is wat trager, maar het is wat

code:

SELECT cat.id,resources.value as title from cat,resources where cat.rid=resources.rid and resources.language=1 ORDER BY title;

Vanmiddag gaan we met n beetje geluk ff aan het testen met het snelheidsverschil.

[Verwijderd]

Ik ben nu overigens al in totaal 3 punten tegengekomen waarin ik MySQL minder vind als PostgeSQL (correct me if I'm wrong) :

- Je kunt geen specifieke row uit je result halen (pg_fetch_row($result,$rijnr) tov mysql_fetch_row($result)) ook kun je dus niet 2 keer door een result lopen

- Je kunt geen meerdere queries achter elkaar plakken doormiddel van ";" je moet dus iedere keer kleine queries uitvoeren.

- Zoals hierboven al genoemd een zeer beperkte mogelijkheid tot functies.

Kan goed zijn dat ik het mis heb maar dit is waar ik in een paar dagen tijd tegen aan gelopen ben.

[MichelVH]

Op dinsdag 25 juni 2002 13:39 schreef gizmonl het volgende:
- Je kunt geen specifieke row uit je result halen (pg_fetch_row($result,$rijnr) tov mysql_fetch_row($result)) ook kun je dus niet 2 keer door een result lopen

mysql_data_seek() is je vriend en daarna kan je gewoon weer mysql_fetch_row() doen. Een eigen functie die hetzelfde doet als pg_fetch_row($result, $rijnr) is dan zo gemaakt lijkt mij.

[Verwijderd]

Ik heb hier eindelijk de benchmarks, de eerste betreft iedere keer 1000 handelingen, en de 2e bij sommige 10000, als ie t niet aan kon 1000, maar dat is snel genoeg aan de tijd te zien: