As I increase concurrency I'm experiencing what I believe are too slow
queries given the minuscule amount of data in my tables.
I have 20 Django worker processes and use ab to generate 3000 requests
to a particular URL which is doing some read only queries. I ran this
with ab concurrency level set
Thank you all for your replies.
I did figure out what is going on.
9.1 is indeed faster than 8.2.11 so we are good to go forward.
Thank you again
--
View this message in context:
http://postgresql.1045698.n5.nabble.com/Slower-Performance-on-Postgres-9-1-6-vs-8-2-11-tp5729749p5729991.html
Sen
Woolcock, Sean wrote:
> A description of what you are trying to achieve and what results
> you expect:
> I have a large (3 million row) table called "tape" that represents
> files, which I join to a small (100 row) table called "filesystem"
> that represents filesystems. I have a web interface
I'm going to push for the upgrade and make the other suggested changes.
Thanks to all for the help,
Sean
From: salah jubeh [s_ju...@yahoo.com]
Sent: Monday, October 29, 2012 3:49 PM
To: stho...@optionshouse.com; Woolcock, Sean
Cc: pgsql-performance@postgre
As shaun has indicated, there is no need for join, also as Joshua suggested, it
is good to upgrade your server. also add indexes for your predicates and
foreign keys and you will get a desired result.
Regards
From: Shaun Thomas
To: "Woolcock, Sean"
Cc:
On 10/29/2012 12:41 PM, Woolcock, Sean wrote:
An example query that's running slowly for me is:
select tape.volser,
tape.path,
tape.scratched,
tape.size,
extract(epoch from tape.last_write_date) as last_write_date,
On 10/29/2012 12:25 PM, Woolcock, Sean wrote:
I thought that an index was implicitly created for foreign keys, but I see that
that's not true. I've just created one now and re-ran the query but it did not
change the query plan or run time.
1. Explain analyze, not explain please
Check to se
I thought that an index was implicitly created for foreign keys, but I see that
that's not true. I've just created one now and re-ran the query but it did not
change the query plan or run time.
Thanks,
Sean
From: salah jubeh [s_ju...@yahoo.com]
Sent: Mo
Shaun Thomas wrote:
> I know that current_date seems like an edge case, but I can't see
> how getting the most recent activity for something is an uncommon
> activity. Tip tracking is actually the most frequent pattern in the
> systems I've seen.
Yeah, this has been a recurring problem with datab
Did you try to add an index on filesystem_id
From: "Woolcock, Sean"
To: "pgsql-performance@postgresql.org"
Sent: Monday, October 29, 2012 6:41 PM
Subject: [PERFORM] Request for help with slow query
Hi, thanks for any help. I've tried to be thorough, but
Hi, thanks for any help. I've tried to be thorough, but let me know if I should
provide more information.
A description of what you are trying to achieve and what results you expect:
I have a large (3 million row) table called "tape" that represents files,
which I join to a small (100 row)
On Mon, Oct 29, 2012 at 6:05 AM, Albe Laurenz wrote:
> I am configuring streaming replication with hot standby
> with PostgreSQL 9.1.3 on RHEL 6 (kernel 2.6.32-220.el6.x86_64).
> PostgreSQL was compiled from source.
>
> It works fine, except that starting the standby took for ever:
> it took the s
On 10/27/2012 10:49 PM, Віталій Тимчишин wrote:
It can be that some query(s) use a lot of work mem, either because of
high work_mem setting or because of planner error. In this case the
moment query runs it will need memory that will later be returned and
become free. Usually this can be seen as
On 10/26/2012 04:08 PM, Tom Lane wrote:
So the bottom line is that this is a case where you need a lot of
resolution in the histogram. I'm not sure there's anything good
we can do to avoid that.
I kinda hoped it wouldn't be something like that. For the particularly
painful instance, it was e
Alvaro Herrera wrote:
>> I am configuring streaming replication with hot standby
>> with PostgreSQL 9.1.3 on RHEL 6 (kernel 2.6.32-220.el6.x86_64).
>> PostgreSQL was compiled from source.
>>
>> It works fine, except that starting the standby took for ever:
>> it took the system more than 80 minutes
Albe Laurenz wrote:
> I am configuring streaming replication with hot standby
> with PostgreSQL 9.1.3 on RHEL 6 (kernel 2.6.32-220.el6.x86_64).
> PostgreSQL was compiled from source.
>
> It works fine, except that starting the standby took for ever:
> it took the system more than 80 minutes to rep
On 10/28/2012 10:06 AM, Tom Lane wrote:
9.2 will only pick the "right" plan if that plan's estimated cost is a
good bit cheaper than the "wrong" parameterized plan.
Is it also possible that the planner differences between extended and
simple query mode caused this? That really bit us in the a
On Mon, Oct 29, 2012 at 02:05:24PM +0100, Albe Laurenz wrote:
> I am configuring streaming replication with hot standby
> with PostgreSQL 9.1.3 on RHEL 6 (kernel 2.6.32-220.el6.x86_64).
> PostgreSQL was compiled from source.
>
> It works fine, except that starting the standby took for ever:
> it t
I am configuring streaming replication with hot standby
with PostgreSQL 9.1.3 on RHEL 6 (kernel 2.6.32-220.el6.x86_64).
PostgreSQL was compiled from source.
It works fine, except that starting the standby took for ever:
it took the system more than 80 minutes to replay 48 WAL files
and connect to
On Mon, Oct 29, 2012 at 10:23 AM, Claudio Freire wrote:
> On Mon, Oct 29, 2012 at 9:09 AM, Matheus de Oliveira
> wrote:
> >> > If you have incremental backup, a restore_command on recovery.conf
> seems
> >> > better than running rsync again when the slave get out of sync.
> Doesn't
> >> > it?
> >
On Mon, Oct 29, 2012 at 9:09 AM, Matheus de Oliveira
wrote:
>> > If you have incremental backup, a restore_command on recovery.conf seems
>> > better than running rsync again when the slave get out of sync. Doesn't
>> > it?
>>
>> What do you mean?
>>
>> Usually, when it falls out of sync like that
On Mon, Oct 29, 2012 at 9:53 AM, Claudio Freire wrote:
> On Mon, Oct 29, 2012 at 7:41 AM, Matheus de Oliveira
> wrote:
>
> >>
> >> Just for the record, we do this quite frequently in our pre-production
> >> servers, since the network there is a lot slower and replication falls
> >> irreparably ou
On Mon, Oct 29, 2012 at 7:41 AM, Matheus de Oliveira
wrote:
> I also think that's a good option for most case, but not because it is
> faster, in fact if you count the whole process, it is slower. But the master
> will be on backup state (between pg_start_backup and pg_stop_backup) for a
> small p
On Sun, Oct 28, 2012 at 9:40 PM, Claudio Freire wrote:
> On Sun, Oct 28, 2012 at 12:15 PM, Karl Denninger
> wrote:
> > 4. pg_start_backup('Upgrading') and rsync the master to the NEW slave
> > directory ex config files (postgresql.conf, recovery.conf and
> pg_hba.conf,
> > plus the SSL keys if yo
24 matches
Mail list logo
