Re: akonadi fsck fails

[ Comments below, in-line ]


On 08/27/2015 01:10 AM, J. Roeleveld wrote:
>
> The NOT EXISTS version was faster. (average around 600ms, the other one
> averages around 800ms)

Hi Joost,

As I initially mentioned, I'm only talking about large data sets.  If
our sets will always be relatively small, I don't particularly worry
about it.  However if we have Use Cases where the data sets will be
large, then it takes very little effort to write performant SQL.


>> I find NOT EXIST to nearly always be non-performant across all RDBMS's.
>
> In one of my projects we did extensive testing on Oracle databases,
> and the NOT EXISTS and EXISTS versions were in 99% of the cases
> faster.

We're a lot off topic here but if you'd like to continue the
discussion, please email me in private.

Timings are not extensive testing.  What's important is to measure the
number of logical I/O's and go from there.  Anyway, please feel free
to email privately with your test results, how you measured your
performance and the version(s) of Oracle.  I know Oracle pretty well.
;)

>> Too bad the LEFT OUTER JOIN doesn't work in the FROM for PG.
>
> I'm not convinced that would actually be faster.  Then again, how
> would you see the DELETE function?  There is logic in the assumption
> that data would be deleted from both tables (if the " IS NULL "
> wouldn't be in the WHERE)

The speed comes in the creation of the selection-set of rows which
will be DELETE'd.

I have repeatedly found NULL OJ's to scale and work well across many
different RDBMS's:  MySQL, PG, Oracle, SQL Server

Anyway, we're also off-topic on this part too.  Feel free to email me
about this as well.  :)

Cheers,
--
Pablo Sanchez - Blueoak Database Engineering, Inc
Ph:    819.459.1926         Blog:  http://pablo-blog.blueoakdb.com
iNum:  883.5100.0990.1054

_______________________________________________
KDE PIM users mailing list
Subscription management: https://mail.kde.org/mailman/listinfo/kdepim-users