Re: Using more tha one index per table

От: Torsten Zühlsdorff
Тема: Re: Using more tha one index per table
Дата: ,
Msg-id: i2eo03$27m$1@news.eternal-september.org
(см: обсуждение, исходный текст)
Ответ на: Re: Using more tha one index per table  (Craig James)
Ответы: Re: Using more tha one index per table  (Craig James)
Список: pgsql-performance

Скрыть дерево обсуждения

Using more tha one index per table  (Elias Ghanem, )
 Re: Using more tha one index per table  ("A. Kretschmer", )
  Re: Using more tha one index per table  (Rob Wultsch, )
   Re: Using more tha one index per table  (Scott Marlowe, )
 Re: Using more tha one index per table  (Scott Marlowe, )
 Re: Using more tha one index per table  (Andy Colson, )
 Re: Using more tha one index per table  (Greg Smith, )
  Re: Using more tha one index per table  (Craig Ringer, )
   Re: Using more tha one index per table  (Craig James, )
    Re: Using more tha one index per table  (Greg Smith, )
     Re: Using more tha one index per table  (Steve Atkins, )
      Re: Using more tha one index per table  (Greg Smith, )
       Re: Using more tha one index per table  (Steve Atkins, )
       Re: Using more tha one index per table  (Richard Huxton, )
        Re: Using more tha one index per table  (Rob Wultsch, )
     Re: Using more tha one index per table  (Craig James, )
     Re: Using more tha one index per table  (Dimitri Fontaine, )
    Re: Using more tha one index per table  (Torsten Zühlsdorff, )
     Re: Using more tha one index per table  (Craig James, )
      Re: Using more tha one index per table  (Torsten Zühlsdorff, )
       Re: Using more tha one index per table  (Craig James, )

Craig James schrieb:

>>> The problem is that Google ranks pages based on inbound links, so
>>> older versions of Postgres *always* come up before the latest version
>>> in page ranking.
>>
>> Since 2009 you can deal with this by defining the canonical-version.
>> (http://googlewebmastercentral.blogspot.com/2009/02/specify-your-canonical.html)
>>
>
> This is a really cool feature, but it's not what we need.  The
> "canonical" refers to the URL, not the web page.  It's only supposed to
> be used if you have multiple URLs that are actually the *same* page; the
> "canonical" URL tells Google "use only this URL for this page."
>
> But in our case, the Postgres manuals for each release have different
> URLs *and* different content, so the "canonical URL" isn't the right
> solution.

This is true, but the content is allowed to change "a little". Of course
their is no percentage of allowed changes. But it can be quite much.
I've used this feature for some clients, which push their content into
very different websites and it does work.
Most of the content of the documentation doesn't change much between the
releases. In most cases the canonical will work the way i suggest.

In case of big changes even the recommandation of using a "current"
version won't work. Its true that Google ranks pages based on inbound
links. But there are more than 200 other factores, which influence the
rankings. Most people do not know, that changing most of a sites content
makes the inbound links for a long time useless. After big changes in
the documentation the "current" entry will be droped for some monthes
and the old entries will appear. But note, that every single site of the
documentation is ranked for itself. From my experience i would expect
the canonical-version with better results, than the current-version.

But the canonical is not the best solution in my opinion. I often edit
the urls of some documentations, because i need it for a special
postgresql version. The documentation clearly misses a version-switch.
Combined with an big note, that the current displayed documentation is
not the one of the current postgresql-version, this will be the best
compromiss in my opinion.

Greetings from Germany,
Torsten


В списке pgsql-performance по дате сообщения:

От: Merlin Moncure
Дата:
Сообщение: Re: Testing Sandforce SSD
От: Yeb Havinga
Дата:
Сообщение: Re: Testing Sandforce SSD