I reported this a while ago and forgot about this until today while I
was doing some debugging and once again got the report of leaked memory.
I'm using the c amalgamation code from 3.7.10 with VStudio 2010, and
always start up my databases setting a temp directory to be used in the
form:
Looking for some performance advice before I go testing this myself.
I'm porting some code that's currently running with SQLite as its DB
engine over to postgres. SQLite will still be an option so I need to
maintain compatibility across both engines. I've run into the common
postgres
Thanks, but I can't do that because I'm batching up multiple writes in
transactions to get performance. The errors cause the whole transaction
to need to be rolled back.
On 8/04/2012 11:20 a.m., Igor Tandetnik wrote:
Josh Gibbsjgi...@imailds.com wrote:
The method that must be used is as
On 12/11/2011 5:02 p.m., Simon Slavin wrote:
On 12 Nov 2011, at 3:43am, Josh Gibbs wrote:
We are struggling to find a way to rework this query in a way
that performs efficiently for large data sets.
It's all about the indexes.
The problem with this query seems to be related
On 13/11/2011 3:37 a.m., Igor Tandetnik wrote:
Josh Gibbsjgi...@imailds.com wrote:
The timestamps are already integers. We stumbled across that CAST operation
optimization purely by accident. I don't remember what led to it, but
we found
that it gave a measurable performance boost casting
On 13/11/2011 3:45 a.m., Igor Tandetnik wrote:
Josh Gibbsjgi...@imailds.com wrote:
To reiterate from my original question, if we don't add the order by then
the results come back at a very acceptable speed. But of course we'd
then have to iterate through the results ourselves to siphon off
Hi all,
We are struggling to find a way to rework this query in a way
that performs efficiently for large data sets.
The goal is to find the top x most active senders of e-mails
within a date range.
The killer of this query is the ORDER BY clause. Without it
the results are quick and snappy.
We've just introduced some memory leak detection into our
code and have discovered that this pragma call is not having its
resources cleaned up at shutdown. It's not a critical leak since
it's only called once at program start, but it would be nice to
have the system report zero memory leaks on
Hi all. We're trying to get the following query working at a better
speed and
I'm wondering if anyone has any ideas on optimizations we might be able
to do.
The query groups e-mail addresses and gives us the total number of each
address seen within a given time range of messages, ordering from
Excellent and perfect solution to my problem. Thanks Richard.
On 23/01/2011 2:16 a.m., Richard Hipp wrote:
On Fri, Jan 21, 2011 at 6:53 PM, Josh Gibbsjgi...@di.co.nz wrote:
Could someone please clarify for me if the the resulting order of a UNION
query will come back with the left data
Could someone please clarify for me if the the resulting order of a UNION
query will come back with the left data first, then the right data in
the case
that no ordering has been defined for the query.
My need is to have a parameter stored in a database, with an optional
overriding parameter
What's the chance that 2 people with the same surname would have
the same problem in the same week...
I believe I just solved the same problem you are asking about yesterday
thanks to a query from Richard:
CREATE TABLE Message (message_id INTEGER PRIMARY KEY AUTOINCREMENT,
Subject TEXT);
On 23/09/2010 11:52 p.m., Richard Hipp wrote:
Josh Gibbsjgi...@imailds.com wrote:
CREATE TABLE Message (message_id INTEGER PRIMARY KEY AUTOINCREMENT,
Subject TEXT);
CREATE TABLE MessageRecipient (message_id INTEGER REFERENCES
Message(message_id) ON DELETE CASCADE, recipient_ID INTEGER
Hi all, I'm hoping someone can assist me with a problem I'm having
creating a cascading delete operation as well as a constraint.
This table is an example of the layout of my data:
CREATE TABLE Message (message_id INTEGER PRIMARY KEY AUTOINCREMENT,
Subject TEXT);
CREATE TABLE MessageRecipient
On 23/09/2010 3:15 p.m., Igor Tandetnik wrote:
Josh Gibbsjgi...@imailds.com wrote:
CREATE TABLE Message (message_id INTEGER PRIMARY KEY AUTOINCREMENT,
Subject TEXT);
CREATE TABLE MessageRecipient (message_id INTEGER REFERENCES
Message(message_id) ON DELETE CASCADE, recipient_ID INTEGER
Hi there,
We are having some problem with DB corruption occurring
using 3.5.4. I don't know the source of the corruption, however
after extensive testing and updating to 3.5.6 in the hope of getting
some resolution to our problems I accidentally ran an older build
of the command line tool and
16 matches
Mail list logo