<?xml version="1.0" encoding="utf-8"?>
<rss version="2.0"><channel><title>Disqus - Latest Comments for Phil Dawes</title><link>http://disqus.com/people/134f0fa845404b3443431687ac9e018f/</link><description></description><language>en</language><lastBuildDate>Tue, 28 Dec 2004 09:02:26 -0000</lastBuildDate><item><title>Re: python cgi vs php</title><link>http://phildawesstuff.disqus.com/python_cgi_vs_php/#comment-2752830</link><description>DB adds between 0.01 and 0.09 of a second in python</description><dc:creator xmlns:dc="http://purl.org/dc/elements/1.1/">Phil Dawes</dc:creator><pubDate>Tue, 01 Jun 2004 14:22:31 -0000</pubDate></item><item><title>Re: importing statements at speed</title><link>http://phildawesstuff.disqus.com/importing_statements_at_speed/#comment-2752885</link><description>That's it - many thanks. &lt;br&gt;&lt;br&gt;Have been thinking about chunked imports too - makes sense with the bulk-import approach since most of the time is spent in the parsing/preparing rather than the actual dumping to db. Chunking it would enable parallelization of the time consuming preparation stage. Would work best with something like 3store, which stores md5 hashes for URIs in its main triples table - no centralization required to agree IDs for URIs. &lt;br&gt;&lt;br&gt;Unfortunately (from this perspective), my store uses generated IDs for URIs to enable a 1:many logical-resource -&amp;gt; URI mapping for smushing. Would probably need to import in chunks and then reconcile IDs in a subsequent sweep.</description><dc:creator xmlns:dc="http://purl.org/dc/elements/1.1/">Phil Dawes</dc:creator><pubDate>Thu, 23 Sep 2004 02:59:06 -0000</pubDate></item><item><title>Re: wordpress installation fixed</title><link>http://phildawesstuff.disqus.com/wordpress_installation_fixed/#comment-2752921</link><description>Testing comments</description><dc:creator xmlns:dc="http://purl.org/dc/elements/1.1/">Phil Dawes</dc:creator><pubDate>Tue, 28 Dec 2004 09:02:26 -0000</pubDate></item></channel></rss>