On Jul 21, 2010, at 7:27 PM, Greg Smith wrote:
> Steve Atkins wrote:
>> If http://postgresql.org/docs/9.0/* were to 302 redirect to
>> http://postgresql.org/docs/current/* while 9.0 is the current release (and
>> similarly for 9.1 and so on) I suspect we'd find many more links to current
>> an
Steve Atkins wrote:
If http://postgresql.org/docs/9.0/* were to 302 redirect to
http://postgresql.org/docs/current/* while 9.0 is the current release (and
similarly for 9.1 and so on) I suspect we'd find many more links to current and
fewer links to specific versions after a year or two.
On Jul 21, 2010, at 6:47 PM, Greg Smith wrote:
> Craig James wrote:
>> By using "current" and encouraging people to link to that, we could quickly
>> change the Google pagerank so that a search for Postgres would turn up the
>> most-recent version of documentation.
>
> How do you propose to en
Craig James wrote:
By using "current" and encouraging people to link to that, we could
quickly change the Google pagerank so that a search for Postgres would
turn up the most-recent version of documentation.
How do you propose to encourage people to do that? If I had a good
answer to that qu
On 7/21/10 5:47 PM, Craig Ringer wrote:
On 21/07/10 22:59, Greg Smith wrote:
A useful trick to know is that if you replace the version number
with "current", you'll get to the latest version most of the time
(sometimes the name of the page is changed between versions, too, but
this isn't that
On 21/07/10 22:59, Greg Smith wrote:
> A useful trick to know is that if you replace the version number
> with "current", you'll get to the latest version most of the time
> (sometimes the name of the page is changed between versions, too, but
> this isn't that frequent).
The docs pages could pe
2010/7/21 Kneringer, Armin :
> Hi Pavel,
>
> Turning hashjoin off also does the trick. (the explain output is below)
> My basic intention was to check if the query planner could be optmized to
> automatically improve the query processing.
> In this case all users (espacially those which are not be
Hi Pavel,
Turning hashjoin off also does the trick. (the explain output is below)
My basic intention was to check if the query planner could be optmized to
automatically improve the query processing.
In this case all users (espacially those which are not be aware of ineffective
query processing
stanimir petrov wrote:
Now the servers are dual core CPU 2.6 with 1.7 GB RAM and i standart
disk. (the small instance from AWS)
You're never going to be able to tune for writing data fast on a AWS
environment; there just isn't enough disk throughput available. If this
application really does
Elias Ghanem wrote:
I red that in PG a query can not use more than one index per table: "a
query or data manipulation command can use at most one index per table".
You'll find that at the very end of
http://www.postgresql.org/docs/7.4/static/indexes.html and
http://www.postgresql.org/docs
Hi
I need to configure for high performance and memory usage my postgres 8.4
clusters.
Description:
The database is partitioned in regions. Every region has master and slave db.
The application write:read=1:50.
At the moment i had delpoyed the app on 3 servers as follows:
Node1: db master2, db
On 7/21/2010 2:31 AM, Elias Ghanem wrote:
Hi,
I have a question concerning the uses of indexes in Postgresql.
I red that in PG a query can not use more than one index per table: "a
query or data manipulation command can use at most one index per table".
Actually I found this a little weird and un
On Wed, Jul 21, 2010 at 1:58 AM, Rob Wultsch wrote:
> On Wed, Jul 21, 2010 at 12:53 AM, A. Kretschmer
> wrote:
>>
>> In response to Elias Ghanem :
>> > Hi,
>> > I have a question concerning the uses of indexes in Postgresql.
>> > I red that in PG a query can not use more than one index per table:
On Wed, Jul 21, 2010 at 1:31 AM, Elias Ghanem wrote:
> Hi,
> I have a question concerning the uses of indexes in Postgresql.
> I red that in PG a query can not use more than one index per table: "a query
> or data manipulation command can use at most one index per table".
> Actually I found this a
On Wed, Jul 21, 2010 at 12:53 AM, A. Kretschmer <
andreas.kretsch...@schollglas.com> wrote:
> In response to Elias Ghanem :
> > Hi,
> > I have a question concerning the uses of indexes in Postgresql.
> > I red that in PG a query can not use more than one index per table: "a
> query or
> > data man
In response to Elias Ghanem :
> Hi,
> I have a question concerning the uses of indexes in Postgresql.
> I red that in PG a query can not use more than one index per table: "a query
> or
> data manipulation command can use at most one index per table".
That's not true, but it's true for MySQL, afa
Hi,
I have a question concerning the uses of indexes in Postgresql.
I red that in PG a query can not use more than one index per table: "a
query or data manipulation command can use at most one index per table".
Actually I found this a little weird and unfortunately I could not find
further expl
17 matches
Mail list logo
