Craig James writes:
> On Wed, May 1, 2013 at 5:18 PM, Tom Lane wrote:
>> It looks like old_str_conntab is more or less clustered by "id",
>> and str_conntab not so much. You could try EXPLAIN (ANALYZE, BUFFERS)
>> (on newer PG versions) to verify how many distinct pages are getting
>> touched du
On 02/05/13 02:06, Tom Lane wrote:
Mark Kirkwood writes:
I am concerned that the deafening lack of any replies to my original
message is a result of folk glancing at your original quick reply and
thinking... incomplete problem spec...ignore... when that is not that
case - yes I should have mutt
On Wed, May 1, 2013 at 5:18 PM, Tom Lane wrote:
> Craig James writes:
> > I have two tables that are nearly identical, yet the same query runs 100x
> > slower on the newer one. ...
>
> > db=> explain analyze select id, 1 from str_conntab
> > where (id >= 12009977 and id <= 12509976) order by id;
Craig James writes:
> I have two tables that are nearly identical, yet the same query runs 100x
> slower on the newer one. ...
> db=> explain analyze select id, 1 from str_conntab
> where (id >= 12009977 and id <= 12509976) order by id;
> Index Scan using new_str_conntab_pkey_3217 on str_connta
I have two tables that are nearly identical, yet the same query runs 100x
slower on the newer one. The two tables have the same number of rows (+/-
about 1%), and are roughly the same size:
db=> SELECT relname AS table_name,
db-> pg_size_pretty(pg_relation_size(oid)) AS table_size,
db-> pg_size_p
On Wed, 2013-05-01 at 17:44 +0200, Stefan de Konink wrote:
> Combined with the recent bugfix regarding hash
> estimation, it gives me a good indication that there might be a bug.
To which recent bugfix are you referring?
The best venue for fixing an issue like this is pgsql-performance -- it
doe
> -Original Message-
>
>
> The original query:
>
> select * from ambit_privateevent_calendars as a, ambit_privateevent as
> b, ambit_calendarsubscription as c, ambit_calendar as d where
> c.calendar_id = d.id and a.privateevent_id = b.id and c.user_id = 1270
> and c.calendar_id = a.c
> -Original Message-
> From: pgsql-performance-ow...@postgresql.org [mailto:pgsql-performance-
> ow...@postgresql.org] On Behalf Of Anne Rosset
> Sent: Wednesday, May 01, 2013 1:10 PM
> To: k...@rice.edu
> Cc: pgsql-performance@postgresql.org
> Subject: Re: [PERFORM] Deterioration in perf
Thanks Ken. I am going to test with different pool sizes and see if I see any
improvements.
Are there other configuration options I should look like? I was thinking of
playing with shared_buffer.
Thanks,
Anne
-Original Message-
From: k...@rice.edu [mailto:k...@rice.edu]
Sent: Wednesday
On Wed, May 1, 2013 at 10:26 AM, k...@rice.edu wrote:
> On Wed, May 01, 2013 at 04:07:55PM +, Anne Rosset wrote:
>> Hi Ken,
>> Thanks for your answer. My test is actually running with jboss 7/jdbc and
>> the connection pool is defined with min-pool-size =10 and max-pool-size=400.
>>
>> Why w
On Wed, May 01, 2013 at 04:07:55PM +, Anne Rosset wrote:
> Hi Ken,
> Thanks for your answer. My test is actually running with jboss 7/jdbc and the
> connection pool is defined with min-pool-size =10 and max-pool-size=400.
>
> Why would you think it is an issue with the connection pool?
>
>
Hi Ken,
Thanks for your answer. My test is actually running with jboss 7/jdbc and the
connection pool is defined with min-pool-size =10 and max-pool-size=400.
Why would you think it is an issue with the connection pool?
Thanks,
Anne
-Original Message-
From: k...@rice.edu [mailto:k...@
Dear Tom,
On Wed, 1 May 2013, Tom Lane wrote:
What can we do to provide a bit more of information?
https://wiki.postgresql.org/wiki/Slow_Query_Questions
There is no particularly good reason to think this is a bug; please
take it up on pgsql-performance if you have more questions.
I beg to
On Wed, May 01, 2013 at 02:05:06PM +, Anne Rosset wrote:
> Hi all,
> We are running a stress test that executes one select query with multiple
> threads.
> The query executes very fast (10ms). It returns 100 rows. I see
> deterioration in the performance when we have multiple threads executi
Mark Kirkwood writes:
> I am concerned that the deafening lack of any replies to my original
> message is a result of folk glancing at your original quick reply and
> thinking... incomplete problem spec...ignore... when that is not that
> case - yes I should have muttered "9.2" in the original
Hi all,
We are running a stress test that executes one select query with multiple
threads.
The query executes very fast (10ms). It returns 100 rows. I see deterioration
in the performance when we have multiple threads executing the query. With 100
threads, the query takes between 3s and 8s.
I
On 26/04/13 15:34, Gavin Flower wrote:
On 26/04/13 15:19, Mark Kirkwood wrote:
While in general you are quite correct - in the above case
(particularly as I've supplied a test case) it should be pretty
obvious that any moderately modern version of postgres on any
supported platform will exhibit
17 matches
Mail list logo
