<?xml version="1.0" encoding="UTF-8"?> 
<?xml-stylesheet href="https://dev.horde.org/themes/horde//default/feed-rss.xsl" type="text/xsl"?> 
<rss version="2.0" xmlns:atom="http://www.w3.org/2005/Atom"> 
 <channel> 
  <title>Optimized Tags </title> 
  <pubDate>Thu, 09 Apr 2026 21:57:57 +0000</pubDate> 
  <link>https://bugs.horde.org/ticket/6982</link> 
  <atom:link rel="self" type="application/rss+xml" title="Optimized Tags " href="https://bugs.horde.org/ticket/6982/rss" /> 
  <description>Optimized Tags </description> 
 
   
   
  <item> 
   <title>The UNION ALL SELECT query is very waste full SQL command. E</title> 
   <description>The UNION ALL SELECT query is very waste full SQL command. Expecially with the kind of table that tags are implemented with. Is taking seconds for my installations with a lot of images. As the server must read all table data to perform the counting and proper selection of data. So we must help the server and perform the count on the rare update operations to have fast common selections. 



The patch:

reorganize the Ansel_Tags object store the store counts of used tags in the tags table to not count on the fly

mark galleries and images if they have tags or not so we can avoid not needed queries with all galleries and images that does not have tags.

Add limit functionality to the tags cloud block</description> 
   <pubDate>Thu, 26 Jun 2008 14:49:39 +0000</pubDate> 
   <link>https://bugs.horde.org/ticket/6982#t46874</link> 
  </item> 
   
  <item> 
   <title>and why not, a tag cloud page...</title> 
   <description>and why not, a tag cloud page...</description> 
   <pubDate>Thu, 26 Jun 2008 14:51:08 +0000</pubDate> 
   <link>https://bugs.horde.org/ticket/6982#t46875</link> 
  </item> 
   
  <item> 
   <title>I&#039;m still looking over the changes here, but why do the iter</title> 
   <description>I&#039;m still looking over the changes here, but why do the iteration/concatenation in gallery.php instead of using implode()?   Is there a big performance difference?</description> 
   <pubDate>Mon, 30 Jun 2008 13:33:40 +0000</pubDate> 
   <link>https://bugs.horde.org/ticket/6982#t46989</link> 
  </item> 
   
  <item> 
   <title>&gt; I&#039;m still looking over the changes here, but why do the 

</title> 
   <description>&gt; I&#039;m still looking over the changes here, but why do the 

&gt; iteration/concatenation in gallery.php instead of using implode()?   

&gt; Is there a big performance difference?



becouse getTags() does not return one dimentional array anymore but even the tag count</description> 
   <pubDate>Mon, 30 Jun 2008 13:37:33 +0000</pubDate> 
   <link>https://bugs.horde.org/ticket/6982#t46990</link> 
  </item> 
   
  <item> 
   <title>&gt; and why not, a tag cloud page...



To be honest, I feel t</title> 
   <description>&gt; and why not, a tag cloud page...



To be honest, I feel that an entire page containing only a tag cloud is a bit, well, boring and wasteful considering that the &quot;Browse&quot; page can be configured with a cloud of whatever size the user wants.   I suppose I can be convinced differently if there is a compelling reason that I am missing or the Cloud page contained some other widgets/info etc...</description> 
   <pubDate>Mon, 30 Jun 2008 13:38:25 +0000</pubDate> 
   <link>https://bugs.horde.org/ticket/6982#t46991</link> 
  </item> 
   
  <item> 
   <title>&gt;&gt; and why not, a tag cloud page...

&gt;

&gt; To be honest, I fe</title> 
   <description>&gt;&gt; and why not, a tag cloud page...

&gt;

&gt; To be honest, I feel that an entire page containing only a tag cloud 

&gt; is a bit, well, boring and wasteful considering that the &quot;Browse&quot; 

&gt; page can be configured with a cloud of whatever size the user wants.



I agree.</description> 
   <pubDate>Mon, 30 Jun 2008 13:56:46 +0000</pubDate> 
   <link>https://bugs.horde.org/ticket/6982#t47001</link> 
  </item> 
   
  <item> 
   <title>It looks like these changes will cause the tag_count field t</title> 
   <description>It looks like these changes will cause the tag_count field to be overwritten with the count of tags in *either* the ansel_images_tags or ansel_galleries_tags table...when it should be both.</description> 
   <pubDate>Mon, 30 Jun 2008 15:54:13 +0000</pubDate> 
   <link>https://bugs.horde.org/ticket/6982#t47004</link> 
  </item> 
   
  <item> 
   <title>&gt; It looks like these changes will cause the tag_count field</title> 
   <description>&gt; It looks like these changes will cause the tag_count field to be 

&gt; overwritten with the count of tags in *either* the ansel_images_tags 

&gt; or ansel_galleries_tags table...when it should be both.



Actually we don&#039;t need to know the actual number of images/galleries tag count. Is used only as a flag if the gallery/image has tags or not to save later queries. So this can be a boolean value.</description> 
   <pubDate>Wed, 02 Jul 2008 07:56:22 +0000</pubDate> 
   <link>https://bugs.horde.org/ticket/6982#t47097</link> 
  </item> 
   
  <item> 
   <title>&gt; Actually we don&#039;t need to know the actual number of images</title> 
   <description>&gt; Actually we don&#039;t need to know the actual number of images/galleries 

&gt; tag count. Is used only as a flag if the gallery/image has tags or 

&gt; not to save later queries. So this can be a boolean value.



Huh?  Your saving the actual number of tags in ansel_tags.tag_count and then your using the value of that field directly in Ansel_Tags::readTags() and Ansel_Tags::listTagInfo().  With your changes, once any tags are added/removed from an image or gallery, the tag counts will never be correct because the value in the ansel_tags.tag_count field is only taking into account the number of times that tag is used in _either_ the images table *or* the galleries table, when it needs to be both.</description> 
   <pubDate>Wed, 02 Jul 2008 20:49:01 +0000</pubDate> 
   <link>https://bugs.horde.org/ticket/6982#t47124</link> 
  </item> 
   
  <item> 
   <title>&gt; Huh?  Your saving the actual number of tags in ansel_tags.</title> 
   <description>&gt; Huh?  Your saving the actual number of tags in ansel_tags.tag_count 



Sorry, that should be &quot;the actual number of times that a tag is used in...&quot;

</description> 
   <pubDate>Wed, 02 Jul 2008 20:50:17 +0000</pubDate> 
   <link>https://bugs.horde.org/ticket/6982#t47125</link> 
  </item> 
   
  <item> 
   <title>Removing as a showstopper, tags work, this would be a nice p</title> 
   <description>Removing as a showstopper, tags work, this would be a nice performance enhancement though, once the gallery vs image tag count issue is resolved.</description> 
   <pubDate>Wed, 16 Jul 2008 03:29:49 +0000</pubDate> 
   <link>https://bugs.horde.org/ticket/6982#t47566</link> 
  </item> 
   
  <item> 
   <title>An extremely simplistic idea for better tag-related queries:</title> 
   <description>An extremely simplistic idea for better tag-related queries:



http://blogs.sun.com/dups/entry/having_a_grand_old_time



Going to try to refactor Ansel&#039;s tag code to see what this gets us, what other issues it might bring up etc....</description> 
   <pubDate>Mon, 20 Oct 2008 18:56:34 +0000</pubDate> 
   <link>https://bugs.horde.org/ticket/6982#t49853</link> 
  </item> 
   
  <item> 
   <title>followup on the having() idea:

http://blogs.sun.com/dups/en</title> 
   <description>followup on the having() idea:

http://blogs.sun.com/dups/entry/having_a_follow_up</description> 
   <pubDate>Tue, 21 Oct 2008 21:02:17 +0000</pubDate> 
   <link>https://bugs.horde.org/ticket/6982#t49873</link> 
  </item> 
   
  <item> 
   <title>&gt; Removing as a showstopper, tags work, this would be a nice</title> 
   <description>&gt; Removing as a showstopper, tags work, this would be a nice 

&gt; performance enhancement though, once the gallery vs image tag count 

&gt; issue is resolved.



And here it is solved. When we fill the ansel_tags table we count both images and galleries table. To be more simple, I reduced the amount of changes just to introduce the tag_count column and avoid the double UNION SELECT. Other performance patches will come after this will be commited.

</description> 
   <pubDate>Fri, 31 Oct 2008 16:21:38 +0000</pubDate> 
   <link>https://bugs.horde.org/ticket/6982#t50224</link> 
  </item> 
   
  <item> 
   <title>1) This patch does nothing to update the count when a tag is</title> 
   <description>1) This patch does nothing to update the count when a tag is removed. You only updating the tags that are passed to Ansel_Tags::writeTags() this function *always* overwrites the resources&#039;s tags, so your not capturing when the tag is removed.



2) Was there any special reason you removed the charset conversion is some of the queries?



3) the variable $id is not always set, that is why I was using the $reults[&#039;tag_id&#039;] value - any special reason you didn&#039;t want to use that?



</description> 
   <pubDate>Thu, 13 Nov 2008 00:55:41 +0000</pubDate> 
   <link>https://bugs.horde.org/ticket/6982#t50712</link> 
  </item> 
   
  <item> 
   <title>Changes have been made in CVS for this ticket:

http://cvs.h</title> 
   <description>Changes have been made in CVS for this ticket:

http://cvs.horde.org/diff.php/ansel/lib/Tags.php?r1=1.87&amp;r2=1.88&amp;ty=u</description> 
   <pubDate>Thu, 13 Nov 2008 01:46:14 +0000</pubDate> 
   <link>https://bugs.horde.org/ticket/6982#t50714</link> 
  </item> 
   
  <item> 
   <title>In the meantime, I changed the search queries to use GROUP B</title> 
   <description>In the meantime, I changed the search queries to use GROUP BY / HAVING to start comparing it with the queries that we had...any feed back on performance is welcome. I&#039;m going to port these changes over to my production server data and see what it gets us.</description> 
   <pubDate>Thu, 13 Nov 2008 01:48:01 +0000</pubDate> 
   <link>https://bugs.horde.org/ticket/6982#t50715</link> 
  </item> 
   
  <item> 
   <title>I think that this can probably be resolved for now, though I</title> 
   <description>I think that this can probably be resolved for now, though I&#039;ll leave it up to Michael. A lot of different options are now available from the Rampage Tagger code in the incubator, including stat tables that take care of caching counts for tags and tags + users (and this adds user_id to the current Ansel structure, allowing folksonomy-type stuff which Ansel doesn&#039;t currently have).



On HAVING vs. the JOIN - HAVING might be quicker in some cases but using a JOIN also lets us exclude tags from the result set, and it also avoids some filesorting most of the time. So the rampage tagger goes with the JOIN solution.</description> 
   <pubDate>Sun, 14 Dec 2008 15:56:12 +0000</pubDate> 
   <link>https://bugs.horde.org/ticket/6982#t51240</link> 
  </item> 
   
  <item> 
   <title>Agreed. This will be taken care of once Ansel is ported to u</title> 
   <description>Agreed. This will be taken care of once Ansel is ported to use the Tagger code.</description> 
   <pubDate>Sun, 14 Dec 2008 17:45:24 +0000</pubDate> 
   <link>https://bugs.horde.org/ticket/6982#t51254</link> 
  </item> 
   
   
 
 </channel> 
</rss> 
