QUERY
SELECT COUNT(*) FROM occurrences WHERE (lat = -27.91550355958 AND lat
= -27.015680440420002 AND lng = 152.13307044728307 AND lng =
153.03137355271693 AND category_id = 1 AND (ST_Intersects(
ST_Buffer(ST_PointFromText('POINT(152.58 -27.465592)')::geography,
1 GB of ram is quite small.
I think it is worth to try creating an index on a combination of
columns(lat, lng).
So that Bitmap Heap Scan would be omitted.
Hi,
I have following table definition with 6209888 rows in it. It stores the
occurrences of species in various regions.
*TABLE DEFINITION*
Column| Type |Modifiers
Some of you may have had annoying problems in the past with autofreeze or
autovacuum running at unexpected moments and dropping the performance of your
server randomly.
On our SSD-RAID10 based system we found a 20GB table finished it's vacuum
freeze in about 100 seconds. There were no
Entire database. People have talked about using SSDs for data/indices and
spinning disks for WAL. However I find having everything on the same disks is
good for 3 reasons.
1. The SSD is simply vastly faster than the disks. That means if huge amount of
WAL is being written out (e.g. tons of
Did you put your entire database on SSD or just the WAL/indexes?
On 28 July 2015 at 23:39, Graeme B. Bell graeme.b...@nibio.no wrote:
Some of you may have had annoying problems in the past with autofreeze or
autovacuum running at unexpected moments and dropping the performance of
your server
Entering production, availability 2016
1000x faster than nand flash/ssd , eg dram-latency
10x denser than dram
1000x write endurance of nand
Priced between flash and dram
Manufactured by intel/micron
Non-volatile
Guess what's going in my 2016 db servers :-)
Please, don't be vapourware...
