In my experience, that 77ms will stay quite constant even if your db grew to > 
1TB.  Postgres IS amazing.  BTW, for a db, you should always have provisioned 
IOPS or else your performance can vary wildly, since the SSDs are shared.


Re Lambda:  another team is working on a new web app using Lambda calls and 
they were also experiencing horrific performance, just like yours (2 seconds 
per call).  They discovered it was the Lambda connection/spin-up time causing 
the problem.  They solved it by keeping several Lambda’s “hot”, for an instant 
connection…solved the problem, the last I heard.  Google for that topic, you’ll 
find solutions.




From: Jean Baro [] 
Sent: Wednesday, December 27, 2017 9:03 AM

Sorry guys,


The performance problem is not caused by PG. 


'Index Scan using idx_user_country on public.old_card  (cost=0.57..1854.66 
rows=460 width=922) (actual time=3.442..76.606 rows=200 loops=1)'

'  Output: id, user_id, user_country, user_channel, user_role, 
created_by_system_key, created_by_username, created_at, last_modified_at, 
date_start, date_end, payload, tags, menu, deleted, campaign, correlation_id'

'  Index Cond: (((old_card.user_id)::text = '1234'::text) AND 
(old_card.user_country = 'BR'::bpchar))'

'  Buffers: shared hit=11 read=138 written=35'

'Planning time: 7.748 ms'

'Execution time: 76.755 ms'


77ms on an 8GB database with 167MM rows and almost 500GB in size is amazing!!


Now we are investigating other bottlenecks, is it the creation of a new 
connection to PG  (no connection poller at the moment, like PGBouncer), is it 
the Lambda start up time? Is it the network performance  between PG and Lambda?


I am sorry for wasting your time guys, it helped us to find the problem though, 
even if it wasn't a PG problem. 


BTW, what a performance! I am impressed. 


Thanks PG community! 


Em 27 de dez de 2017 14:34, "Jean Baro" < 
<> > escreveu:

Thanks Jeremy,


We will provide a more complete EXPLAIN as other people have suggested. 


I am glad we might end up with a much better performance (currently each query 
takes around 2 seconds!).





Em 27 de dez de 2017 14:02, "Jeremy Finzel" < 
<> > escreveu:





'Index Scan using idx_user_country on card  (cost=0.57..1854.66 rows=460 

'  Index Cond: (((user_id)::text = '4684'::text) AND (user_country = 


Show 3 runs of the full explain analyze plan on given condition so that we can 
also see cold vs warm cache performance.


There is definitely something wrong as there is no way a query like that should 
take 500ms.  Your instinct is correct there.


Reply via email to