Re: Comparing PostgreSQL and Oracle stability
От | CoL |
---|---|
Тема | Re: Comparing PostgreSQL and Oracle stability |
Дата | |
Msg-id | ag42bu$i6q$1@news.hub.org обсуждение исходный текст |
Ответ на | Re: Comparing PostgreSQL and Oracle stability (Jan Pruner <jan@pruner.cz>) |
Список | pgsql-general |
Once it was here, so I paste to you:) Oracle: with variables &TypNiv = 0 et &Niv = 0 select sum(t01_caf) SCAF, sum(t01_itm_cnt) SART from T01_&DateData start with T01_upr_lvl_typ = &TypNiv and T01_upr_lvl_nbr = &Niv connect by prior T01_lvl_typ = T01_upr_lvl_typ and prior T01_lvl_nbr = T01_upr_lvl_nbr Postgres: \set TypNiv 0 \set Niv 0 select sum(t01_caf) as SCAF, sum(t01_itm_cnt) as SCAF from t01_20011231 where strpos(t01_tree_sortkey,(select t01_tree_sortkey from t01_20011231 where t01_upr_lvl_typ = :TypNiv and t01_upr_lvl_nbr = :Niv))=1; C. Jan Pruner wrote: > Support PostgreSQL in some way hierarchical query like Oracle does? > Select ... start with ... connect by ... ??? > > JP > > On Thursday 04 July 2002 11:18, you wrote: > >>>I'm considering porting code from Oracle to PostgreSql. I'm looking >>>for opinions from people that are experienced with both PostgreSQL and >>>Oracle: >>> >>>1) Is the stability better, equal or worse when comparing Oracle 9i? >>>2) Are there any performance issues to be aware of when comparing >>>PostgreSql an d Oracle (on the same hardware configuration) - eg. size >>>of table colums, count of records in tables (and indexes). >>>3) And how about the work for DB administrators - are things simpler >>>or more complicated? >> >>First off, I don't have much experience with Oracle, but I have done a >>couple things with it, and one of my colleagues has used it much more >>extensively. >> >>1) stability - I have not had stability problems with a recent release of >>postgresql. The developers sometimes mention potential problems, but I >>haven't encountered one (at least after 7.1, before that I seem to rememb= > > er > >>a couple minor issues). I haven't heard of any problems with oracle. >> >>2) I can't provide you with any meaningful info about performance. I didn= > > 't > >>do any scientific performance comparison. One thing I can say, is that my >>colleague needed to spend a lot of time giving hints to oracle because >>(according to him) the planner was really bad and frequently made planning >>errors. >> >>3) Much easier to administrate postgres. I gave up trying to get oracle >>working myself. >> >>Regards, >> Jeff >> >> >> >>---------------------------(end of broadcast)--------------------------- >>TIP 1: subscribe and unsubscribe commands go to majordomo@postgresql.org > > > --=20 > Pruner Jan > jan@pruner.cz > http://jan.pruner.cz/ > ----------------------------- > Only Robinson Crusoe had all his work done by Friday > > > > ---------------------------(end of broadcast)--------------------------- > TIP 5: Have you checked our extensive FAQ? > > http://www.postgresql.org/users-lounge/docs/faq.html > >
В списке pgsql-general по дате отправления: