On Sun, 22 Nov 2009, Jonathan Blitz wrote:
I have a table with a number of columns.
I perform
Select *
from table
order by a,b
There is an index on a,b which is clustered (as well as indexes on a and b
alone).
I have issued the cluster and anyalze commands.
Did you analyse *after*
On Sun, 22 Nov 2009, Richard Neill wrote:
Worse still, doing a cluster of most of the tables and vacuum full analyze
Why are you doing a vacuum full? That command is not meant to be used
except in the most unusual of circumstances, as it causes bloat to
indexes.
If you have run a cluster
Definitely after.
Jonathan
-Original Message-
From: pgsql-performance-ow...@postgresql.org
[mailto:pgsql-performance-ow...@postgresql.org] On Behalf Of Matthew
Wakeling
Sent: Monday, November 23, 2009 1:00 PM
To: Jonathan Blitz
Cc: pgsql-performance@postgresql.org
Subject: Re: [PERFORM]
2009/11/20 Jonathan Foy the...@gmail.com:
Shy of just throwing a trigger in the
table to actually populate a second table with the same data solely for
reporting purposes,
That's what I would do in your situation, FWIW. Query optimization is
a hard problem even under the best of
On Sun, Nov 22, 2009 at 10:31 AM, Richard Neill rn...@cam.ac.uk wrote:
Dear All,
Thanks for your help earlier with the previous question. I wonder if I might
ask another.
We have various queries that need to run, of which I'm going to focus on 2,
vox and du_report.
Both of them are
On 01/-10/-28163 11:59 AM, afancy wrote:
Hi,
My PostgreSQL server has two CPUs (OS: Fedora 11), each with 4 cores.
Total is 8cores. Now I have several clients running at the same time
to do insert and update on the same table, each client having its own
connection. I have made two testing
Tom Lane wrote:
Lorenzo Allegrucci lorenzo.allegru...@forinicom.it writes:
So, my main question is.. how can just a plain simple restart of postgres
restore the original performance (3% cpu time)?
Are you killing off any long-running transactions when you restart?
After three days of
Question:
Is an INSERT command with a SELECT statement in the RETURNING * parameter
faster than say an INSERT and then a SELECT? Does the RETURNING * parameter
simply amount to a normal SELECT command on the added rows? We need to
basically insert a lot of rows as fast as possible, and get the
Bill Moran wmo...@potentialtech.com writes:
In response to Lorenzo Allegrucci lorenzo.allegru...@forinicom.it:
Tom Lane wrote:
Are you killing off any long-running transactions when you restart?
Anyway, how can I get rid those idle in transaction processes?
Can I just kill -15 them or is
On Mon, Nov 23, 2009 at 1:53 PM, Jason Dictos jdic...@barracuda.com wrote:
Question:
Is an INSERT command with a SELECT statement in the RETURNING * parameter
faster than say an INSERT and then a SELECT? Does the RETURNING * parameter
simply amount to a normal SELECT command on the added
Hi everybody,
I've got two queries that needs optimizing. Actually, there are others,
but these are pretty representative.
You can see the queries and the corresponding plans at
http://bulldog.duhs.duke.edu/~faheem/snpdb/opt.pdf
or
http://bulldog.duhs.duke.edu/~faheem/snpdb/opt.tex
if
2009/11/23 Faheem Mitha fah...@email.unc.edu
Hi everybody,
I've got two queries that needs optimizing. Actually, there are others, but
these are pretty representative.
You can see the queries and the corresponding plans at
http://bulldog.duhs.duke.edu/~faheem/snpdb/opt.pdf
or
On Mon, 23 Nov 2009, Thom Brown wrote:
Hi Faheem,
There appears to be a discrepancy between the 2 PDFs you provided. One
says you're using PostgreSQL 8.3, and the other shows you using common
table expressions, which are only available in 8.4+.
Yes, sorry. I'm using Postgresql 8.4. I
On Tue, Nov 24, 2009 at 12:49 AM, Faheem Mitha fah...@email.unc.edu wrote:
Yes, sorry. I'm using Postgresql 8.4. I guess I should go through diag.pdf
and make sure all the information is current. Thanks for pointing out my
error.
excellent report!
about the copy problem: You seem to have
How often are the tables you query from updated?
Rgds
Sebastian
On Tue, Nov 24, 2009 at 12:52 AM, marcin mank marcin.m...@gmail.com wrote:
On Tue, Nov 24, 2009 at 12:49 AM, Faheem Mitha fah...@email.unc.edu
wrote:
Yes, sorry. I'm using Postgresql 8.4. I guess I should go through
diag.pdf
On Tue, 24 Nov 2009, Sebastian Jörgensen wrote:
How often are the tables you query from updated?
Quite rarely. Once in a while. The large tables, eg. geno, are basically
static.
Regards, Faheem.
Rgds
Sebastian
On Tue, Nov 24,
Dear all,
The query is slow when executing in the stored procedure(it is taking
around 1 minute). when executing as a sql it is taking 4 seconds.
basically i am selecting the varchar column which contain 4000 character. We
have as iindex on the table. We have analyzed the table also. What
2009/11/24 ramasubramanian ramasubramania...@renaissance-it.com:
Dear all,
The query is slow when executing in the stored procedure(it is taking
around 1 minute). when executing as a sql it is taking 4 seconds.
basically i am selecting the varchar column which contain 4000 character. We
In response to ramasubramanian :
Dear all,
The query is slow when executing in the stored procedure(it is taking
around 1 minute). when executing as a sql it is taking 4 seconds.
basically i am selecting the varchar column which contain 4000 character. We
have as iindex on the table. We
Thanks a lot Pavel . i will try it .
- Original Message -
From: Pavel Stehule pavel.steh...@gmail.com
To: ramasubramanian ramasubramania...@renaissance-it.com
Cc: pgsql-performance@postgresql.org
Sent: Tuesday, November 24, 2009 11:40 AM
Subject: Re: [PERFORM] Query is slow when
Thanks a lot Kretschmer. i will try it .
Regards,
Ram
- Original Message -
From: A. Kretschmer andreas.kretsch...@schollglas.com
To: pgsql-performance@postgresql.org
Sent: Tuesday, November 24, 2009 11:45 AM
Subject: Re: [PERFORM] Query is slow when executing in procedure
In
21 matches
Mail list logo
