Thanks Grzegorz,
But work memory is for each process (connection) rt? so if i keep
more then 10MB will not affect the overall performance ?
Arvind S
2009/10/12 Grzegorz Jaśkiewicz
> btw, what's the version of db ?
> what's the work_mem setting ?
>
> try setting work_mem to higher value
Sorry guys, i sent the required plan
QUERY
PLAN
--
Merge Left Join (cost=62422.81..67
Thanks very much Matthew , its more then my expectation...
Without changing the query is there any way to optimize it, like by changing
the pg configuration for handling these kind queries?
-Arvind S
On Mon, Oct 12, 2009 at 6:31 PM, Matthew Wakeling wrote:
> On Mon, 12 Oct 2009, S Arv
I can understand left join, actually can any one tell me why sort operation
is carried out and wat Materialize means...
Can anyone explain me the mentioned plan with reason(s)?
-Arvind S
2009/10/12 Grzegorz Jaśkiewicz
>
>
> On Mon, Oct 12, 2009 at 12:21 PM, S Arvind wrote:
>
>
In the below query both table has less than 1 million data. Can u tell me
the reason of this plan?
why its takin extensive cost , seq scan and sorting?? wat is Materialize?
select 1 from service_detail
left join non_service_detail on non_service_detail_service_id =
service_detail.service_detail_i
Thanks Robert,
So for our scenario what is the most important factor to be noted
for performance.
-Arvind S
On Sat, Oct 3, 2009 at 12:49 AM, Robert Haas wrote:
> On Thu, Oct 1, 2009 at 4:11 AM, S Arvind wrote:
> > In some docs i read that shared buffer must be increased bas
Eric thanks. And its not 200 differnet server , its only single pg8.3
handling 200+ dbs.
Arvind S
"Many of lifes failure are people who did not realize how close they were to
success when they gave up."
-Thomas Edison
On Thu, Oct 1, 2009 at 8:26 PM, Haszlakiewicz, Eric
wrote:
> >-Original
Thanks Jean,
So from the discussion is it true that performance will be same across
all newly upgraded linux is it?
Thanks,
Arvind S
*
"Many of lifes failure are people who did not realize how close they were to
success when they gave up."
-Thomas Edison
*
On Thu, Oct 1, 2009 at 3:44 PM, Jea
seprate .
Thanks,
Arvind S
"Many of lifes failure are people who did not realize how close they were to
success when they gave up."
-Thomas Edison
On Thu, Oct 1, 2009 at 3:34 PM, Jean-David Beyer wrote:
> S Arvind wrote:
>
>> Hi everyone,
>> What is the best Linux
Hi everyone,
What is the best Linux flavor for server which runs postgres alone.
The postgres must handle greater number of database around 200+. Performance
on speed is the vital factor.
Is it FreeBSD, CentOS, Fedora, Redhat xxx??
-Arvind S
In some docs i read that shared buffer must be increased based on the
maximum dataset size. For my scenario the dataset size is relative small
less then a Gb, but database# handled by a server is nearly 200db per
server and average connection# to server will be >500 (approx 5/per each
DB). So for
In single server(4gb ram 2 core 2 duo), which design is good for
performance?
1) single installation for 200 db with 800 tables/db
or
2) Two installation (instance) running on different port with each
handling 100 db.
Which of this design is good for postgres where our goal is high
perfor
Thanks Tom Lane,
I think we must have to consider about your last mail words. But now
reducing the table is mearly impossible, but very thanks for advice , we
will try it in future.
-Arvind S
On Sun, Jun 7, 2009 at 4:42 AM, Tom Lane wrote:
> S Arvind writes:
> > So do i have to
7, 2009 at 4:32 AM, Tom Lane wrote:
> S Arvind writes:
> > So is it no use running
> > vacuumdb --all --analyze --full
> > as fsm map is full?
>
> Well, it's not of *no* use. But you'd be well advised to crank up the
> FSM size.
>
>
, Jun 7, 2009 at 4:15 AM, Tom Lane wrote:
> S Arvind writes:
> > But there nearly only 300 tables in that db. Is the free space map is
> per
> > DB or for all DB. Can i know the reason of this problem?
>
> It's across all DBs in the installation.
>
>regards, tom lane
>
So is it no use running
vacuumdb --all --analyze --full
as fsm map is full?
-Arvind S
On Sun, Jun 7, 2009 at 4:24 AM, S Arvind wrote:
> Thanks Tom,
> So do i have to increase the max_fsm_relation based on (Average_no_relation
> per db * number of db)? if so it will be very high sin
should i have to increase max_fsm_relations more. If yes why i have to ?
Since number of relation is less only.
--Arvind S
On Sun, Jun 7, 2009 at 4:06 AM, S Arvind wrote:
> Found a notice after completing the
> vacuumdb -p 5433 -- all --analyze --full -v
> max_fsm_relation
Found a notice after completing the
vacuumdb -p 5433 -- all --analyze --full -v
max_fsm_relation = 1400 in postgresql.conf
Thou all our 50 db individually have less then 1400 relation , when it
completes , there was NOTICE that increase the max_fsm_relation.
INFO: free space map contains 10344 p
s not more efficient Smith?
-Arvind S
*
"Many of lifes failure are people who did not realize how close they were to
success when they gave up."
-Thomas Edison
*
On Mon, Jun 1, 2009 at 9:04 PM, Greg Smith wrote:
> On Mon, 1 Jun 2009, S Arvind wrote:
>
> Having a doubt, we wa
Having a doubt, we want to vacuum and reindex some 50 most used tables
daily on specific time. Is it best to have a function in postgres and call
it in cron or is there any other good way to do the two process for
specified tables at specified time?
-Arvind S
*
**"Many of lifes failure are people
20 matches
Mail list logo
