Thanks a lot Kretschmer. i will try it .
Regards,
Ram
- Original Message -
From: "A. Kretschmer"
To:
Sent: Tuesday, November 24, 2009 11:45 AM
Subject: Re: [PERFORM] Query is slow when executing in procedure
In response to ramasubramanian :
Dear all,
The query is slow when ex
Thanks a lot Pavel . i will try it .
- Original Message -
From: "Pavel Stehule"
To: "ramasubramanian"
Cc:
Sent: Tuesday, November 24, 2009 11:40 AM
Subject: Re: [PERFORM] Query is slow when executing in procedure
2009/11/24 ramasubramanian :
Dear all,
The query is slow when execut
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.
2009/11/24 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 h
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 cou
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, 200
How often are the tables you query from updated?
Rgds
Sebastian
On Tue, Nov 24, 2009 at 12:52 AM, marcin mank wrote:
> On Tue, Nov 24, 2009 at 12:49 AM, Faheem Mitha
> wrote:
> >
> > Yes, sorry. I'm using Postgresql 8.4. I guess I should go through
> diag.pdf
> > and make sure all the informat
On Tue, Nov 24, 2009 at 12:49 AM, Faheem Mitha 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 created the primar
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 gue
2009/11/23 Faheem Mitha
>
> 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.
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 you
On Mon, Nov 23, 2009 at 1:53 PM, Jason Dictos 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 rows? We need to
> ba
Bill Moran writes:
> In response to Lorenzo Allegrucci :
>> 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 there a less drastic way to do it?
> Connectio
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
Tom Lane wrote:
Lorenzo Allegrucci 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 patient waiting it looks like the comm
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 te
On Sun, Nov 22, 2009 at 10:31 AM, Richard Neill 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 extreme
2009/11/20 Jonathan Foy :
> 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 circumstances; getting the
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]
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 co
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* creati
21 matches
Mail list logo
