Re: [PERFORM] DELETE takes too much memory

Well, basically there are only INSERTs going on there (it is a table holding audit records for each DML statement). I do not see how a DELETE statement could block an INSERT? You are correct that rebuilding the table will be faster, but then, there is a chance that some INSERT's will be blocked an

Re: [PERFORM] Tuning guidelines for server with 256GB of RAM and SSDs?

Hi, We had a similar situation and the best performance was with 64MB background_bytes and 512 MB dirty_bytes. Tigran. On Jul 5, 2016 16:51, Kaixi Luo wrote:Hello,I've been reading Mr. Greg Smith's "Postgres 9.0 - High Performance" book and I have some questions regarding the guidelines I found

Re: [PERFORM] DELETE takes too much memory

On 07/04/2016 10:10 AM, Kouber Saparev wrote: > No. There are AFTER triggers on other tables that write to this one > though. It is an audits table, so I omitted all the foreign keys on purpose. Is it possible that the DELETE blocked many of those triggers due to locking the same rows? Incidental

Re: [PERFORM] less than 2 sec for response - possible?

Hi, yes I've tried it in the past, it makes no any difference at all: With TIMESTAMP cast: QUERY PLAN HashAggregate (cost=1405666.90..1416585.93 rows=335970 width=86) (actual time=4794.585..4923.062 rows=126533 loops=1) " Group Key: subid, sid" Buffers: shared hit=1486949 -> Index Scan

[PERFORM] Tuning guidelines for server with 256GB of RAM and SSDs?

Hello, I've been reading Mr. Greg Smith's "Postgres 9.0 - High Performance" book and I have some questions regarding the guidelines I found in the book, because I suspect some of them can't be followed blindly to the letter on a server with lots of RAM and SSDs. Here are my server specs: Intel X

[PERFORM] Seeing execution plan of foreign key constraint check?

Hi, I was wondering whether there are any plans to include the plan of the FK check in EXPLAIN output. Or is there a different way to get to see all the plans of triggers as well as of the main SQL? When researching I found this thread from 2011 and the output format does not seem to have changed

Re: [PERFORM] less than 2 sec for response - possible?

On 02.07.2016 02:54, trafdev wrote: Hi. I'm trying to build an OLAP-oriented DB based on PostgresSQL. User works with a paginated report in the web-browser. Interface allows to fetch data for a custom date-range selection, display individual rows (20-50 per page) and totals (for entire select

Re: [PERFORM] less than 2 sec for response - possible?

Hello Have you solved your problem ? Could it be a conversion overhead from 'timestamp without time zone' to 'date' ? In this case, I don't know if planer store constants as date or timestamp. Mathieu Pujol Le 02/07/2016 à 04:48, trafdev a écrit : Thanks Tom. I've created index on aid, da