[asterisk-dev] [Code Review] 3841: Fix Regression From AstDB I/O Performance Improvement Patch

Tilghman Lesher reviewboard at asterisk.org
Wed Jul 23 13:58:10 CDT 2014


-----------------------------------------------------------
This is an automatically generated e-mail. To reply, visit:
https://reviewboard.asterisk.org/r/3841/#review12839
-----------------------------------------------------------


As long as you're doing multiple statements, might it be faster to do a SELECT first and then conditionally do an INSERT or UPDATE, depending upon the results of that SELECT?  It would seem as if one read and one write operation should always be faster than two write operations.

- Tilghman Lesher


On July 23, 2014, 5:21 p.m., Michael Young wrote:
> 
> -----------------------------------------------------------
> This is an automatically generated e-mail. To reply, visit:
> https://reviewboard.asterisk.org/r/3841/
> -----------------------------------------------------------
> 
> (Updated July 23, 2014, 5:21 p.m.)
> 
> 
> Review request for Asterisk Developers and Joshua Colp.
> 
> 
> Bugs: ASTERISK-24050
>     https://issues.asterisk.org/jira/browse/ASTERISK-24050
> 
> 
> Repository: Asterisk
> 
> 
> Description
> -------
> 
> The CI testing found a regression with the last patch.  Yea!  The UPDATE was not functioning as expected.  I am pretty sure I tested UPDATES but obviously missed something.
> 
> sqlite3_prepare() does not handle multiple SQL statements in a single call.  If there are more than one present, it will only use the first statement and ignore the rest.
> 
> This patch separates the INSERT INTO and the UPDATE into two separate statements for use by sqlite3_prepare.  These two statements are then run when ast_db_put() is called.
> 
> 
> Diffs
> -----
> 
>   /trunk/main/db.c 419309 
> 
> Diff: https://reviewboard.asterisk.org/r/3841/diff/
> 
> 
> Testing
> -------
> 
> I turned on tracing in order to see this problem and also to confirm that this patch was functioning again as expected. 
> 
> I ran the testsuite test that was failing before the patch and then after the patch to confirm that the test no passes as well.
> 
> 
> Thanks,
> 
> Michael Young
> 
>

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.digium.com/pipermail/asterisk-dev/attachments/20140723/8c84368b/attachment.html>


More information about the asterisk-dev mailing list