Re: [Phpwiki-talk] Ampersand

[Martin G. <gim...@gi...>]

Jeff Dairiki <da...@da...> writes:

(Shouldn't that replay go to the list? If so, then you can just post
your reply to this mail there...)

>> Also, the LIKE search is expensive if it cannot use an index. The
>> manual for MySQL actually says that it can't:
>
> Interesting (& good) points.  I still suspect it's a fairly large
> performance win to have mysql do the iterative search rather than doing
> in PHP.  (You avoid the mysql->PHP communcation and the mysql code,
> while using the same basic search algorithm is written in C rather
> than PHP.)

Yes, that should give MySQL better performance... It also depends on
where the MySQL and web server is located --- on the same machine so
that they can communicate using a local unix socket or on different
machines which means real network trafic...

> On the other hand, maybe PhpWiki over-all is slow enough that the
> difference is unimportant.   I guess it would take some experiments to
> find out.  (The answer, I suspect depends heavily on the size of
> the wiki, too...)

Yes, I'm not sure either that it would make much of a difference with
all those other lines of PHP code that's executed all the time :-)

I've played a bit with the new full-text index in MySQL and it works
OK. It was just a quick hack where I stored the original search query
in the TextSearchQuery class and then added a text_search() to the
WikiDB_backend_mysql class. So the highlight is wrong.

> Anyhow, none of that is currently high on my list of priorities...
>
> One of these days, (after user-auth and other things have
> stabilized) it might be good to refactor the backends and SQL schema
> a bit.

I think that would be nice. I noticed how the database is locked and
unlocked with each operation, even on backends like PostgreSQL (and
now also MySQL with InnoDB) that support transactions. This seams to
be something that could benefit from a cleanup.

> (Pagetype and the cached markup should each be in their own column,
> rather than stored in the general meta-data hash.) But that's for
> some other time...

Yes, there's plenty of other things to hack on :-)

> (Another project would be to implement a real word index, so that
> the SQL searches would be indexed.)

That sounds like a good idea --- the more work we can do when saving
the pages, the better.

A similar thing would be a plugin that generates an index like the
ones you find in the back of most books. I'm not sure if this can be
done automatically, but the plugin could skip words that appear on
more than perhaps 10% of the pages or something like that. And it
should also skip words on a stoplist.

Such a plugin would be cool for fast, exported sites where you cannot
do a dynamic search. I'm beginning to think of PhpWiki as a tool that
can be used to quickly build static sites: it's quick and easy to
update the contents, the linking capabilities are great. And the look
of everything is controlled by the template system.

-- 
Martin Geisler                       My GnuPG Key: 0xF7F6B57B

See http://gimpster.com/ and http://phpweather.net/ for:
PHP Weather => Shows the current weather on your webpage and
PHP Shell   => A telnet-connection (almost :-) in a PHP page.