On 11.10.2016 03:47, Pavel Stehule
wrote:
2016-10-10 23:17 GMT+02:00 Andrzej
Zawadzki <zawa...@gmail.com>:
On
10.10.2016
On 10.10.2016 17:31, Andrzej Zawadzki
wrote:
Hi,
Today, I noticed strange situation:
The same query run on different servers has very different plan:
Q: SELECT b.* FROM kredytob b WHERE pesel = '222' ORDE
On 10.10.2016 19:09, Pavel Stehule
wrote:
2016-10-10 17:31 GMT+02:00 Andrzej
Zawadzki <zawa...@wp.pl>:
Hi,
Today, I noticed strange situation:
Th
sel = '222'::bpchar)"
" Buffers: shared hit=14661 read=4576"
"Planning time: 0.383 ms"
"Execution time: 463.324 ms"
Data is almost equal - "slow" has a few more rows in table. ("Fast"
is a copy from 1 am today).
Why runtime is slower?
--
Andrzej Zawadzki
On 10.01.2013 19:48, Matheus de Oliveira wrote:
>
>
> On Thu, Jan 10, 2013 at 11:32 AM, Andrzej Zawadzki <mailto:zawa...@wp.pl>> wrote:
>
> Hi!
>
> Small query run on 9.0 very fast:
>
> SELECT * from sygma_arrear sar where sar.arrea
On 10.01.2013 19:17, Jeff Janes wrote:
> On Thu, Jan 10, 2013 at 5:32 AM, Andrzej Zawadzki wrote:
>> Why that's happens? All configurations are identical. Only engine is
>> different.
> Could you post explain (analyze, buffers) instead of just explain?
Impossible, 1h of
ize (cost=0.00..447641.42 rows=6126357
width=4)"**
**" -> Seq Scan on sygma_arrear sa
(cost=0.00..393077.64 rows=6126357 width=4)"**
**" Filter: (arrear_flag_id = 2)"**
*
Seq scan... slooow.
Why that's happens? All conf
On 08.10.2012 17:56, Tom Lane wrote:
> Andrzej Zawadzki writes:
>> On 08.10.2012 16:52, Tom Lane wrote:
>>> [ counts... ] You've got nine base relations in that query. I think
>>> you need to increase from_collapse_limit and/or join_collapse_limit.
>> Bin
On 08.10.2012 16:52, Tom Lane wrote:
> Andrzej Zawadzki writes:
>> I have no idea whats wrong. Looks like planer bad decision.
> [ counts... ] You've got nine base relations in that query. I think
> you need to increase from_collapse_limit and/or join_collapse_limit.
>
On 08.10.2012 12:15, Craig Ringer wrote:
> On 10/08/2012 04:18 PM, Andrzej Zawadzki wrote:
>> Hi!
>>
>> After upgrade (dump/restore/analyze) query (below) after some time is
>> killed by kernel.
>
> What's `shared_buffers`? `work_mem`?
shared_buffers = 64M
1 width=0)"
" Index Cond: (credit_id = $3)"
" Filter: (id > $2)"
" -> Index Scan using linie_pkey on linie l (cost=0.00..2.77
rows=1 width=40)"
"In
Andrzej Zawadzki wrote:
> Tom Lane wrote:
>
>> Andrzej Zawadzki writes:
>>
>>
>>> # EXPLAIN ANALYZE SElect telekredytid from kredytyag
>>> WHERE TRUE
>>> AND kredytyag.id = 3064776
>>> AND NOT EXISTS
>>> (SELECT
Andrzej Zawadzki wrote:
> Tom Lane wrote:
>
>> Andrzej Zawadzki writes:
>>
>>
>>> # EXPLAIN ANALYZE SElect telekredytid from kredytyag
>>> WHERE TRUE
>>> AND kredytyag.id = 3064776
>>> AND NOT EXISTS
>>> (SELECT
Tom Lane wrote:
> Andrzej Zawadzki writes:
>
>> # EXPLAIN ANALYZE SElect telekredytid from kredytyag
>> WHERE TRUE
>> AND kredytyag.id = 3064776
>> AND NOT EXISTS
>> (SELECT 1 FROM
>> ( SELECT * FROM kredyty kr
>> where telekredytid = 328650
>
|
telekredytid | integer |
default (-1)
Indexes:
"kredyty_pkey" PRIMARY KEY, btree (id) CLUSTER
"kredyty_kredytagid_id_idx" UNIQUE, btree (kredytagid, id)
"kredyty_datazaw" btree (datazaw)
"kredyty_telekredytid_id
id_idx on
kredyty kr (cost=0.00..78.50 rows=94 width=3910)"
" Index Cond: (telekredytid = 328652)"
" -> Index Scan using kredytyag_pkey on kredytyag (cost=0.00..6.30
rows=1 width=4)"
"Index Cond: (id = 3064776)"
I've chosen bad index?
--
Andrzej Zawadzki
--
Sent via pgsql-performance mailing list (pgsql-performance@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-performance
id_idx on
kredyty kr (cost=0.00..78.50 rows=94 width=3910)"
" Index Cond: (telekredytid = 328652)"
" -> Index Scan using kredytyag_pkey on kredytyag (cost=0.00..6.30
rows=1 width=4)"
"Index Cond: (id = 3064776)"
I've chosen bad index?
--
Andrzej Zawadzki
--
Sent via pgsql-performance mailing list (pgsql-performance@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-performance
I have such situation at work. Size of database on disk is 60GB and is
stable.
--
Andrzej Zawadzki
--
Sent via pgsql-performance mailing list (pgsql-performance@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-performance
Knight, Doug wrote:
> Hi,
> As a gauge, we recently purchased several servers as our systems get
> close to going operational. We bought Dell 2900s, with the cheapest quad
> core processors (dual) and put most of the expense into lots of drives
> (8 15K 146GB SAS drives in a RAID 10 set), and the P
Craig Ringer wrote:
> Andrzej Zawadzki wrote:
>
>> Hello,
>>
>> We're planning new production server for PostgreSQL and I'm wondering
>> which processor (or even platform) will be better: Quad Xeon or Quad
>> Opteron (for example SUN now has a ne
for performance?
Do You have any opinions? Suggestions?
Thanks,
Best regards
--
Andrzej Zawadzki
--
Sent via pgsql-performance mailing list (pgsql-performance@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-performance
That's email from my friend.
Any hint?
Original Message
Subject: bug
Date: Wed, 09 May 2007 15:03:00 +0200
From: Michal Postupalski
To: Andrzej Zawadzki
We've just changed our database from 8.1 to 8.2 and we are
grief-stricken about very poor performance with que
e Oct 18 21:19:23 UTC 2005 x86_64
Dual_Core_AMD_Opteron(tm)_Processor_875 unknown PLD Linux
Why new PostgreSQL is slower?
--
Andrzej Zawadzki
---(end of broadcast)---
TIP 5: don't forget to increase your free space map settings
23 matches
Mail list logo
