Re: Using more tha one index per table

From: Craig James <craig_james(at)emolecules(dot)com>
To: pgsql-performance(at)postgresql(dot)org
Subject: Re: Using more tha one index per table
Date: 2010-07-24 14:59:36
Message-ID: 4C4AFFD8.8000004@emolecules.com
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-docs pgsql-performance

On 7/24/10 5:57 AM, Torsten Zühlsdorff wrote:
> 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.

Here's an idea: Use a "current" URL, plus a JavaScript embedded in every page that compares its own URL to the "current" URL and, if it doesn't match, does a "document.write()" indicating how to find the most-current version.

That would solve three problems:

1. There would be a "current" version that people could link to.
2. If someone found an old version, they would know it and could
instantly be directed to the current version.
3. It wouldn't be any burden on the web site maintainers, because
the JavaScript wouldn't have to be changed.

Craig

In response to

Browse pgsql-docs by date

  From Date Subject
Next Message Robert Haas 2010-07-24 22:26:35 Re: Please provide stable target anchors
Previous Message John Gage 2010-07-24 14:26:11 Re: Adding a crucial element to an example

Browse pgsql-performance by date

  From Date Subject
Next Message Ben Chobot 2010-07-24 16:50:24 Re: Testing Sandforce SSD
Previous Message Torsten Zühlsdorff 2010-07-24 12:57:38 Re: Using more tha one index per table