From mboxrd@z Thu Jan 1 00:00:00 1970 X-Spam-Checker-Version: SpamAssassin 3.4.4 (2020-01-24) on polar.synack.me X-Spam-Level: X-Spam-Status: No, score=-1.9 required=5.0 tests=BAYES_00,FREEMAIL_FROM autolearn=unavailable autolearn_force=no version=3.4.4 X-Received: by 10.182.22.65 with SMTP id b1mr7960438obf.10.1399719843227; Sat, 10 May 2014 04:04:03 -0700 (PDT) X-Received: by 10.140.27.40 with SMTP id 37mr1062qgw.24.1399719843200; Sat, 10 May 2014 04:04:03 -0700 (PDT) Path: border2.nntp.ams3.giganews.com!backlog4.nntp.ams3.giganews.com!backlog4.nntp.ams.giganews.com!border2.nntp.ams.giganews.com!nntp.giganews.com!proxad.net!feeder2-2.proxad.net!nx02.iad01.newshosting.com!newshosting.com!news.glorb.com!c1no4074693igq.0!news-out.google.com!dz10ni36309qab.1!nntp.google.com!hw13no2051366qab.0!postnews.google.com!glegroupsg2000goo.googlegroups.com!not-for-mail Newsgroups: comp.lang.ada Date: Sat, 10 May 2014 04:04:03 -0700 (PDT) In-Reply-To: <304f2721-64bc-4959-a7e8-0cc29cf5204f@googlegroups.com> Complaints-To: groups-abuse@google.com Injection-Info: glegroupsg2000goo.googlegroups.com; posting-host=46.195.148.91; posting-account=3_reEwoAAAC163IAIrx427KYmwahFuh9 NNTP-Posting-Host: 46.195.148.91 References: <304f2721-64bc-4959-a7e8-0cc29cf5204f@googlegroups.com> User-Agent: G2/1.0 MIME-Version: 1.0 Message-ID: Subject: Re: Ada and PL/pgSQL ? From: =?ISO-8859-1?Q?bj=F6rn_lundin?= Injection-Date: Sat, 10 May 2014 11:04:03 +0000 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable X-Original-Bytes: 2512 Xref: number.nntp.dca.giganews.com comp.lang.ada:186343 Date: 2014-05-10T04:04:03-07:00 List-Id: Den fredagen den 9:e maj 2014 kl. 18:26:22 UTC+2 skrev sdale...@gmail.com: >With a majority of the slow down occuring from table locks on db transacti= ons. Thinking a bit of this. If you have the same figures with Postgres, as you state, then I wonder if your code is explicitly locking the tables? As in issuing a statement like 'LOCK TABLE XYZ' or 'SELECT XYZ for UPDATE' That is killing performance in any db. If so, and you migrate that principle, you will always have performance iss= ues. If so, you'll need to use other mechanisms to ensure your data is untampere= d with, as in having versions/timestamps on each row, and check that the ro= w-version you first read, is the same at write (essentially using a where-c= lause having 'where version=3Doriginally_read_version' in it.=20 And if rows affected is 0, rollback and start-over, given you wanted to upd= ate 1 row). Scoop of transactions becomes very important here Basically, what my posts are trying to say is that the timings you describe will likely not get better by putting your logic i= n the database. Putting you logic in Ada, will however likely make your mai= ntenance burden a lot easier /Bj=F6rn