[pmwiki-users] SQLite pagelist recipe prerelease
Christopher Cox
ccox at endlessnow.com
Sun Aug 26 15:02:38 CDT 2012
Free text word searching (which is probably behind the OP's performance
and pagelist, etc issue).. is also something better suited to a
dictionary word search db thing... stuff like htDig did for static
HTML... things like nepomuk also come to mind. So.. I think you may
need something that creates a high speed lookup into the flat files for
free text searches maybe?
(afterthought to my prior post)
On 08/26/2012 02:58 PM, Christopher Cox wrote:
> Can't say for sure. But figure that PTVs (for example) are just (more
> or less) name,value pairs. So... an RDMS unless there are clear
> benefits to be had using some kind of relationship joins across
> tables... well... it's likely the wrong tool for the job in many
> cases. Not saying that you might have been PTV bound here.... just
> saying... PmWiki does come with a pagelist cache mechanism (which can
> help in some cases).
>
> So... at least for me, the concern would be more focused on users of
> lots of PTVs and how that might impact performance if the number of
> pages got really, really large. In those cases, a name,value db might
> help.
>
> If you believe that there are many strong row/columns style RDBMS
> relations that somehow fit into the operation of PmWiki, then maybe a
> RDBMS fits... I'm thinking it's the wrong tool for the job at the
> moment though.
>
> You have to remember, things like sqlite are built on top of the same
> (performance wise) file system as the (sort of) indexed flat files
> that sit behind PmWiki. It wouldn't surprise me if used for page
> fetches and stores that sqlite is actually slower.
>
> Just saying... (these are however, very, very cursory thoughts...
> somebody else probably KNOWS better)
>
>
> On 08/26/2012 02:48 PM, Alex Eftimiades wrote:
>> I have been trying to redesign some of the common pagelist
>> functionality to take advantage of an sqlite installation. You just
>> include it after you set your WikiDir to the custom SQLite pagestore
>> class. Like the person who sent out the updated pmwiki skin, I was
>> looking for some feedback/comments on the implementation and whether
>> you think this might help speed up pagelists on an sqlite
>> installation with a lot of pages.
>>
>> This actually has not helped speed up my own pagelists as much as I
>> thought it would. In fact, I do not really notice a difference at
>> all! Then again, I only have about 550 pages on my site. Perhaps I
>> would notice more of a difference if I had several hundred thousand.
>> All the more reason I wanted some feedback on the implementation.
>> Right now, it takes care of the name=, group=, link=, and order=
>> statements using SQLite queries. I hope to extend it to do the page
>> (text) variable specifications and if statements as well.
>>
>> It uses a few custom functions to do FmtPageName for less standard
>> order=$Name type declarations and to check if the link= is in the
>> targets of the current page it is looking at. I would assume that
>> would make the sqlite query closer to just using php, but I thought
>> it would make a difference doing the testing on each page as they are
>> read from the database rather than reading them all from the database
>> into memory and sifting through the results from there. I could be
>> wrong, and this might not help at all, or perhaps only help in
>> certain situations.
>>
>> Let me know if you have any insight on this.
>>
>> Thanks,
>> Alex
>>
>>
>>
>> _______________________________________________
>> pmwiki-users mailing list
>> pmwiki-users at pmichaud.com
>> http://www.pmichaud.com/mailman/listinfo/pmwiki-users
>
>
> _______________________________________________
> pmwiki-users mailing list
> pmwiki-users at pmichaud.com
> http://www.pmichaud.com/mailman/listinfo/pmwiki-users
More information about the pmwiki-users
mailing list