Re: [PERFORM] bitmap heap scan recheck for gin/fts with no lossy blocks

On Thu, Jul 23, 2015 at 9:58 AM, Laurent Debacker wrote: > Hi, > > I have read that GIN indexes don't require a recheck cond for full text > search as long as work_mem is big enough, otherwise you get lossy blocks, > and the recheck cond. > > In my case, I have no lossy blocks (from what I could

[PERFORM] bitmap heap scan recheck for gin/fts with no lossy blocks

Hi, I have read that GIN indexes don't require a recheck cond for full text search as long as work_mem is big enough, otherwise you get lossy blocks, and the recheck cond. In my case, I have no lossy blocks (from what I could tell), but I do have a recheck... EXPLAIN (ANALYZE, BUFFERS) SELECT CO

[PERFORM] parallelisation provides postgres performance (script example + ppt slides)

Hi all, 1. For those that don't like par_psql (http://github.com/gbb/par_psql), here's an alternative approach that uses the Gnu Parallel command to organise parallelism for queries that take days to run usually. Short script and GIS-focused, but may give you a few ideas about how to paralleli

Re: [PERFORM] hyperthreadin low performance (and some discussion about benchmarking)

On 23 Jul 2015, at 13:37, domenico febbo wrote: > is the problem also in PostgreSQL 9.4.x? > I'm going to buy a production's server with 4 sockets E7-4850 12 cores > so 12*4 = 48 cores (and 96 threads using HT). > > What do you suggest? > Using or not HT? > > BR 1. If you have enough money to

Re: [PERFORM] hyperthreadin low performance

is the problem also in PostgreSQL 9.4.x? I'm going to buy a production's server with 4 sockets E7-4850 12 cores so 12*4 = 48 cores (and 96 threads using HT). What do you suggest? Using or not HT? BR Domenico 2015-07-21 11:07 GMT+02:00 Mark Kirkwood : > On 21/07/15 20:04, David Rowley wrote: >> >