Re: Implement sql/sqlite database for pacman local database

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]




2016/10/23 20:42、Alive 4ever <alive4ever@xxxxxxxx> のメッセージ:

>> On Sun, Oct 23, 2016 at 01:57:23AM -0400, Eli Schwartz via arch-general wrote:
>> On 10/23/2016 01:41 AM, Alive 4ever wrote:
>>>> Also consider the fact that your pacman database is one of the least
>>>> likely pieces of data to target for the sake of noticeably improving
>>>> your computer's overall performance.
>>>> 
>>> 
>>> Yeah, I am aware of it. Hardware components tend to degrade over time,
>>> especially mechanical hard drive.
>> 
>> What part of "least likely pieces of *data*" was not obvious enough in
>> its reference to *data*, such that you felt the need to conflate data
>> with hardware?
>> 
>> If you are agreeing with me ("Yeah, I am aware of it") then stop
>> mentioning hardware.
>> If you are arguing with me, then please explain what you actually meant
>> to say and what it has to do with hardware.
>> 
>> ...
> Back to the subject, I wanted to propose my idea on how to speed up
> pacman local database access - regardless of the hardware.
> 
> Some folks replied with something like ``there is no need for this, just
> go get an ssd``, which is misleading.
> 
> I post the idea here as suggestion for  pacman local database improvement,
> not as complaint on slow filesystem access on mechanical drive.
> 
>> 
>> I am still pretty sure that whatever problem you may have, it is not
>> pacman-specific and it doesn't require a pacman-specific tool.
>> 
>> So while you might disagree with the political commentary invoked in
>> that commit message, the general idea that the script is a waste of
>> space is something I can get behind!
> 
> While using sql for pacman database could potentially provide faster
> access to local database, there is a risk of database corruption that
> isn't easy to recover. Current approach of using smaller files for
> databases also has its own advantage as gsnijder explained.
> 
>> One really big advantage of this approach is that you don't have to worry
>> about corrupted databases. It's been a while since I used an RPM based
>> distro, but it always surprised me how quickly the db would fall over and
>> needed to be rebuilt.
>> The beauty of the Arch approach is it's robust simplicity. And yes, there
>> are/were wrappers that use a SQL DB for specific operations. If such a db
>> gets problems, there is nothing to worry about: pacman just keeps working
>> anyway.
> 
> I'll leave it to developers to take whichever methods for pacman local
> database.

In my mind, There is actually good side and bad side.

in a good side of SQL db, Faster access, fast query, can read with simpler method...

in a bad side of SQL db, If power lost during writing, surely DB will corrput and not easy to recover.




[Index of Archives]     [Linux Wireless]     [Linux Kernel]     [ATH6KL]     [Linux Bluetooth]     [Linux Netdev]     [Kernel Newbies]     [Share Photos]     [IDE]     [Security]     [Git]     [Netfilter]     [Bugtraq]     [Yosemite News]     [MIPS Linux]     [ARM Linux]     [Linux Security]     [Linux RAID]     [Linux ATA RAID]     [Samba]     [Device Mapper]
  Powered by Linux