On 08/08/2016 02:03 AM, Dominique Pellé wrote:
Kevin O'Gorman wrote:
CREATE INDEX has two problems:
1) poor default location of temporary storage.
2) gets wedged on very large indexes.
I'm using the sqlite that came with Xubuntu 14.04, I think it's version
3.8.2.
SQLite-3.8.2 is old (Dec 2013
On Sun, Aug 7, 2016 at 12:03 PM, Dominique Pellé
wrote:
> Kevin O'Gorman wrote:
>
> > CREATE INDEX has two problems:
> > 1) poor default location of temporary storage.
> > 2) gets wedged on very large indexes.
> >
> > I'm using the sqlite that came with Xubuntu 14.04, I think it's version
> > 3.8
Kevin O'Gorman wrote:
> CREATE INDEX has two problems:
> 1) poor default location of temporary storage.
> 2) gets wedged on very large indexes.
>
> I'm using the sqlite that came with Xubuntu 14.04, I think it's version
> 3.8.2.
SQLite-3.8.2 is old (Dec 2013). It's better to download and
compile
> Does anybody know where the actual defaults and controlling environment
> variables are documented, by operating system?
https://www.sqlite.org/tempfiles.html
--
Meilleures salutations, Met vriendelijke groeten, Best Regards,
Olivier Mascia (from mobile device), integral.be/om
_
RETRACTED: Not wedged, just somewhat slower than I expected. I was
expecting about an hour, and it takes 6. On reflection, it's okay. My
ideas about what's going on were wrong too -- anonymous files are used, but
only two of them at a time.
I still think it is using a poor choice of default dir
Rob,
At 18:27 07/08/2016, you wrote:
Too little sleep and far too much coffee.
I was in the same situation, multiplying by 2 instead of dividing, as
Ryan pointed out.
Nice to see that WAL fits your use case. I for one found it rock solid
and very useful.
--
Jean-Christophe
___
On Sat, Aug 6, 2016 at 2:49 PM, Kevin O'Gorman
wrote:
> On Sat, Aug 6, 2016 at 2:09 AM, Dan Kennedy wrote:
>
>> On 08/06/2016 09:52 AM, Kevin O'Gorman wrote:
>>
>>> On Fri, Aug 5, 2016 at 2:03 PM, Dan Kennedy
>>> wrote:
>>>
>>> On 08/06/2016 03:28 AM, Kevin O'Gorman wrote:
On Fri, Aug
Jean-Christophe
Thanks for the update on wal-mode. Your explanation is clear and makes
sense to us. We can see what we would have a 224MB -wal file, we
experimented with killing processes whilst updating and generally
messing around and SQLite did what is was supposed to do. I wouldn’t
say we
Ryan,
Thanks for the update.
We have done a few more tests during the day and not had any issues to
date. This is still on a test version but we are getting a warm, cuddly
feeling about using WAL mode.
The -wal file grows as you describe and you have explained it very well.
We were groping
Andrii Motsok wrote:
> Is that possible to switch database from WAL to DELETE mode when holding more
> than one connection?
No. There is no mechanism to tell the other connections about the change.
> If no, which workaround could we use
Don't do it. What problem do you think you can solve wit
On 2016/08/07 8:55 AM, Rob Willett wrote:
Richard, Ryan,
Thanks for this. We were dimly aware of WAL but until now hadn’t
needed to use it.
We’ve done a quick check with it and it *seems* to work on a test
database. We’ve all read the docs again and paid attention to
https://www.sqlite.or
Hi,
Is that possible to switch database from WAL to DELETE mode when holding more
than one connection? If no, which workaround could we use to omit closing of
'all-except-one' connections?
Regards,
Andrii
___
sqlite-users mailing list
sqlite-users@
Rob,
At 08:55 07/08/2016, you wrote:
We think that using WAL mode works for us, indeed inspection seems to
indicate it does, but the size of the -wal file appears to be far
larger than would be expected. Is there a problem here? It doesn't
appear to be a problem but would welcome any comments.
13 matches
Mail list logo