Hi,
> -Ursprüngliche Nachricht-
> Von: [EMAIL PROTECTED]
> [mailto:[EMAIL PROTECTED] Im Auftrag
> von Joost Kraaijeveld
> Gesendet: Dienstag, 6. Dezember 2005 10:44
> An: Pgsql-Performance
> Betreff: [PERFORM] Can this query go faster???
> SELECT customers.objectid FROM prototype.custo
> -Ursprüngliche Nachricht-
> Von: [EMAIL PROTECTED]
> [mailto:[EMAIL PROTECTED] Im Auftrag
> von Markus Wollny
> Gesendet: Montag, 5. Dezember 2005 16:41
> An: Tom Lane
> Cc: pgsql-performance@postgresql.org
> Betreff: Re: [PERFORM] Queries taking ages in P
> -Ursprüngliche Nachricht-
> Von: Tom Lane [mailto:[EMAIL PROTECTED]
> Gesendet: Montag, 5. Dezember 2005 16:12
> An: Markus Wollny
> Cc: pgsql-performance@postgresql.org
> Betreff: Re: AW: AW: [PERFORM] Queries taking ages in PG 8.1,
> have been much faster in
> -Ursprüngliche Nachricht-
> Von: Tom Lane [mailto:[EMAIL PROTECTED]
> Gesendet: Montag, 5. Dezember 2005 15:33
> An: Markus Wollny
> Cc: pgsql-performance@postgresql.org
> Betreff: Re: AW: [PERFORM] Queries taking ages in PG 8.1,
> have been much faster in PG&l
Hi!
> -Ursprüngliche Nachricht-
> Von: Tom Lane [mailto:[EMAIL PROTECTED]
> Gesendet: Sonntag, 4. Dezember 2005 19:32
> An: Markus Wollny
> Cc: pgsql-performance@postgresql.org
> Betreff: Re: [PERFORM] Queries taking ages in PG 8.1, have
> been much faster in PG
Title: RE: [PERFORM] Queries taking ages in PG 8.1, have been much faster in PG<=8.0
Hi!
> -Ursprüngliche Nachricht-
> Von: Tom Lane [mailto:[EMAIL PROTECTED]]
> Gesendet: Donnerstag, 1. Dezember 2005 17:26
> An: Markus Wollny
> Cc: pgsql-performance@postgresql
> -Ursprüngliche Nachricht-
> Von: Tom Lane [mailto:[EMAIL PROTECTED]
> Gesendet: Donnerstag, 1. Dezember 2005 17:26
> An: Markus Wollny
> Cc: pgsql-performance@postgresql.org
> Betreff: Re: [PERFORM] Queries taking ages in PG 8.1, have
> been much faster in PG<
Hi!
I've got an urgent problem with an application which is evaluating a
monthly survey; it's running quite a lot of queries like this:
select SOURCE.NAME as TYPE,
count(PARTICIPANT.SESSION_ID) as TOTAL
from (
select PARTICIPANT.SESSION_ID
from survey.PARTICIPANT,
survey.ANSWE
Hi!
> -Ursprüngliche Nachricht-
> Von: [EMAIL PROTECTED]
> [mailto:[EMAIL PROTECTED] Im Auftrag
> von Richard Huxton
> Gesendet: Dienstag, 25. Oktober 2005 12:07
> An: Markus Wollny
> Cc: pgsql-performance@postgresql.org
> Betreff: Re: [PERFORM] Strange p
Hello!
I've got a table BOARD_MESSAGE (message_id int8, thread_id int8, ...)
with pk on message_id and and a non_unique not_null index on thread_id.
A count(*) on BOARD_MESSAGE currently yields a total of 1231171 rows,
the planner estimated a total of 1232530 rows in this table. I've got
pg_autova
[EMAIL PROTECTED] wrote:
> Next we'll upgrade the postgres hardware, and then I'll come
> back to report if it's working better... sorry for the noise for now.
There have been some discussions about which hardware suits PostgreSQL's
needs best under certain load-characteristics. We have experienc
[EMAIL PROTECTED] wrote:
>>> Have you tried reindexing your active tables?
> It will cause some performance hit while you are doing it. It
> sounds like something is bloating rapidly on your system and
> the indexes is one possible place that could be happening.
You might consider using contrib/
Hello!
We're using PostgreSQL 8.0.1 as general backend for all of our websites,
including our online forums (aka bulletin boards or whatever you wish to
call that). As for full text search capabilities, we've chosen to
implement this via tsearch2. However, the tables themselves are quite
large, a
13 matches
Mail list logo
