Re: [PERFORM] 3000x Slower query when using Foreign Data Wrapper vs. local

Hi Mohammad, I think it's not enable "use_remote_estimate" during the creation of the foreign table http://www.postgresql.org/docs/9.4/static/postgres-fdw.html use_remote_estimate This option, which can be specified for a foreign table or a foreign server,

Re: [PERFORM] 3000x Slower query when using Foreign Data Wrapper vs. local

enabled by default because they would be more authoritative and > more representative of access patterns. Correct ? > > Best Regards, > Mohammad > > On Sun, Oct 11, 2015 at 5:42 PM, desmodemone <desmodem...@gmail.com> > wrote: > >> Hi Mohammad, >&

Re: [PERFORM] updating statistics on slow running query

2014-11-10 18:43 GMT+01:00 Eric Ramirez eric.ramirez...@gmail.com: Hi, I have created a sample database with test data to help benchmark our application. The database has ten million records, and is running on a dedicated server(postgres 9.3) with 8GB of RAM. Our queries are pretty slow

Re: [PERFORM] Postgresql 9.3 for a Mobile Backend

2014-05-08 9:10 GMT+02:00 Rajiv Kasera rajiv.kas...@pinelabs.com: Dear Community friends, We are planning to use postgresql 9.3 for building a mobile backend. Can we get a benchmark on the level of concurrency that can be supported by Postgres 9.3 and it will be able to handle the spike in

Re: [PERFORM] HFS+ pg_test_fsync performance

2014-04-15 0:32 GMT+02:00 Mel Llaguno mllag...@coverity.com: I was given anecdotal information regarding HFS+ performance under OSX as being unsuitable for production PG deployments and that pg_test_fsync could be used to measure the relative speed versus other operating systems (such as

Re: [PERFORM] Why shared_buffers max is 8GB?

Il 26/mar/2014 13:36 Ilya Kosmodemiansky ilya.kosmodemian...@postgresql-consulting.com ha scritto: Hi Alexey, On Wed, Mar 26, 2014 at 1:21 PM, Alexey Vasiliev leopard...@inbox.ru wrote: I read from several sources, what maximum shared_buffers is 8GB. I believe that was an issue on some

Re: [PERFORM] Why shared_buffers max is 8GB?

Yes, I rember was 1024*G*b , sorry, 2014-03-26 14:23 GMT+01:00 Albe Laurenz laurenz.a...@wien.gv.at: desmodemone wrote: max is 1024mb. That must be a typo. It can surely be much higher. Yours, Laurenz Albe

Re: [PERFORM] pg_dump vs pg_basebackup

2014-03-25 15:56 GMT+01:00 Joshua D. Drake j...@commandprompt.com: On 03/25/2014 05:05 AM, Claudio Freire wrote: On Tue, Mar 25, 2014 at 4:39 AM, David Johnston pol...@yahoo.com wrote: Hai, Can anyone tell me the difference and performance between pgdump and pg_basebackup if I want to

Re: [PERFORM] Query taking long time

) Index Cond: ((name)::text = 'ranitidine'::text) Total runtime: 79967.705 ms (6 rows) Any other idea? Thank you very much for your help. Regards, Andrés El Mar 6, 2014, a las 2:11 PM, desmodemone escribió: Il 05/mar/2014 00:36 Venkata Balaji Nagothi vbn...@gmail.com ha scritto

Re: [PERFORM] Query taking long time

Il 05/mar/2014 00:36 Venkata Balaji Nagothi vbn...@gmail.com ha scritto: After looking at the distinct values, yes the composite Index on name and hepval is not recommended. That would worsen - its expected. We need to look for other possible work around. Please drop off the above Index. Let

Re: [PERFORM] postgres performance

2013/12/7 chidamparam muthusamy mchidampa...@gmail.com hi, thank you so much for the input. Can you please clarify the following points: *1. Output of BitmapAnd = 303660 rows* - BitmapAnd (cost=539314.51..539314.51 rows=303660 width=0) (actual time=9083.085..9083.085 rows=0 loops=1)

Re: [PERFORM] Recommendations for partitioning?

Hi Dave, About the number of partitions , I didn't have so much problems with hundreds of partitions ( like 360 days in a year ). Moreover you could bypass the overhead of trigger with a direct insert on the partition, also to have a parallel insert without to firing too much the

Re: [PERFORM] WAL + SSD = slow inserts?

Hello, could you please post the postgresql version, the postgresql.conf, the operative system used, the kernel version and the filesystem used ? Thank you 2013/12/5 Skarsol skar...@gmail.com I'm trying to increase the speed of inserts in a database that is on a not super fast

Re: [PERFORM] Speed up the query

Hello, your problem seems to arises from the sort that id sone to disk : - Sort (cost=221247.80..223164.10 rows=766519 width=376) (actual time=50731.687..54455.528 rows=737662 loops=1) Sort Key: qry1.id, qry1.nama, qry1.kodebarang, qry1.namabarang

Re: [PERFORM] UNION versus SUB SELECT

Could you please attache the plan with explain buffers verbose? thank you 2013/11/21 Robert DiFalco robert.difa...@gmail.com UNION and subselect both performed better than EXISTS for this particular case. On Thu, Nov 21, 2013 at 12:31 PM, desmodemone desmodem...@gmail.comwrote: Hi

Re: [PERFORM] UNION versus SUB SELECT

Hi Robert, could you try with exists ? SELECT c.* FROM contacts c WHERE exists ( SELECT 1 FROM phone p WHERE p.addr =? and p.contact_id= c.id ) OR exists (SELECT 1 FROM email e WHERE e.addr = ? and e.contact_id=c.id ); 2013/11/21 Robert DiFalco robert.difa...@gmail.com I have found

Re: [PERFORM] Slow index scan on B-Tree index over timestamp field

Hello, I think you could try with an index on tweet table columns user_id, creation_time [in this order , because the first argument is for the equality predicate and the second with the range scan predicate, the index tweet_user_id_creation_time_index is not ok because it has the