[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