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.
