Any idea or suggestions how to improve my database best
performance.???
Regards
Hashim
On Sat, Oct 29, 2011 at 9:40 AM, Mohamed Hashim wrote:
> Thanks Alban & Gregg.
>
>
> i will describe little more about that table
>
>
>- We are using PHP application with Apache server & P
Robert Haas writes:
> On Wed, Oct 19, 2011 at 12:42 PM, Greg Jaskiewicz wrote:
>> When I do an insert on table B, the database check if value for column
>> table_a_id exists in table A
>> But, if I do an update of column address of table B, does the database
>> check again?
> I just tested t
Claudio Freire writes:
> On Mon, Oct 31, 2011 at 2:08 PM, Robert Haas wrote:
>>> Multicolumn indices on (c1, c2, ..., cn) can only be used on where
>>> clauses involving c1..ck with k> I don't think that's true. I believe it can be used for a query that
>> only touches, say, c2. It's just extre
On Mon, Oct 31, 2011 at 10:34 AM, Albe Laurenz wrote:
> Heikki Linnakangas wrote:
>>> We selected a 30MB bytea with psql connected with
>>> "-h localhost" and found that it makes a huge
>>> difference whether we have SSL encryption on or off.
>>>
>>> Without SSL the SELECT finished in about a seco
On Mon, Oct 31, 2011 at 2:34 PM, Claudio Freire wrote:
> On Mon, Oct 31, 2011 at 3:24 PM, Robert Haas wrote:
>> Sure it does:
>>
>> rhaas=# create table baz (a bool, b int, c text, primary key (a, b));
>> NOTICE: CREATE TABLE / PRIMARY KEY will create implicit index
>> "baz_pkey" for table "baz"
On Mon, Oct 31, 2011 at 3:24 PM, Robert Haas wrote:
> Sure it does:
>
> rhaas=# create table baz (a bool, b int, c text, primary key (a, b));
> NOTICE: CREATE TABLE / PRIMARY KEY will create implicit index
> "baz_pkey" for table "baz"
> CREATE TABLE
> rhaas=# insert into baz select true, g,
> ran
On Mon, Oct 31, 2011 at 1:52 PM, Claudio Freire wrote:
> On Mon, Oct 31, 2011 at 2:08 PM, Robert Haas wrote:
>>> Multicolumn indices on (c1, c2, ..., cn) can only be used on where
>>> clauses involving c1..ck with k>
>> I don't think that's true. I believe it can be used for a query that
>> only
On Wed, Oct 19, 2011 at 12:42 PM, Greg Jaskiewicz wrote:
> For example:
> Table A
> -id (PK)
> -name
>
> Table B
> -table_a_id (PK, FK)
> -address
>
> When I do an insert on table B, the database check if value for column
> “table_a_id” exists in table A
> But, if I do an update of column “address
On Mon, Oct 31, 2011 at 2:08 PM, Robert Haas wrote:
>> Multicolumn indices on (c1, c2, ..., cn) can only be used on where
>> clauses involving c1..ck with k
> I don't think that's true. I believe it can be used for a query that
> only touches, say, c2. It's just extremely inefficient.
Does post
Just tested on 9.0.5, seems ok. Explain for the suspected sub query is now in
line with Analyze.
Thanks
Jens
"Jens Reufsteck" writes:
> I’ve got a lengthy query, that doesn't finish in reasonable time (i.e.
> 10min+). I suspect, that the query optimizer miscalculates the number of
> rows for p
On Tue, Oct 11, 2011 at 8:52 PM, Claudio Freire wrote:
> On Tue, Oct 11, 2011 at 5:16 PM, Carlo Stonebanks
> wrote:
>> Question 2) Regardless of the answer to Question 1 - if another_id is not
>> guaranteed to be unique, whereas pkey_id is – there any value to changing
>> the order of declaration
Note the file number appearing in the lseeks, run "lsof -p PID" against
the backend process to discover the actual filename of that file, then
look for a match to the filename in pg_class.relfilenode.
Will do. I need to reproduce the error first which may take a while.
I have attached two of t
Heikki Linnakangas wrote:
>> We selected a 30MB bytea with psql connected with
>> "-h localhost" and found that it makes a huge
>> difference whether we have SSL encryption on or off.
>>
>> Without SSL the SELECT finished in about a second,
>> with SSL it took over 23 seconds (measured with
>> \tim
=?ISO-8859-1?Q?S=F6ren_Meyer-Eppler?= writes:
>> embedded in often-executed plpgsql functions, for instance. Can you
>> identify which table the lseeks are issued against?
> I wouldn't know how? I'm just using htop and "s" on the postgres process
> to find these...
Note the file number appeari
embedded in often-executed plpgsql functions, for instance. Can you
identify which table the lseeks are issued against?
I wouldn't know how? I'm just using htop and "s" on the postgres process
to find these...
(Now, having said that, I don't see how that type of theory explains no
CPU load.
(1) is it *only* that query?
No. There seem to be one or two others exhibiting similarly bad performance.
(2) is there some reason you might have excessive disk fragmentation,
like running on a VM?
No VM. The database is the only thing running on the server. Filesystem
is XFS.
--
Sent via
Hi Tomas,
and thank you for your reply.
Inline my comments
> -Original Message-
> From: Tomas Vondra [mailto:t...@fuzzy.cz]
> Sent: 28 October 2011 8:10 PM
> To: Sorbara, Giorgio (CIOK)
> Cc: pgsql-performance@postgresql.org
> Subject: Re: [PERFORM] Strange query plan
>
> Hi,
>
> On 2
17 matches
Mail list logo
