Re: Huge shared hit for small table

: On Mon, Nov 4, 2019 at 12:38 PM Scott Rankin wrote: > Definitely no long-running transactions on this table; in fact, this table is pretty infrequently updated – on the order of a few tens of rows updated per day. But a long running transaction will have an impact on all tables --

Re: Huge shared hit for small table

Definitely no long-running transactions on this table; in fact, this table is pretty infrequently updated – on the order of a few tens of rows updated per day. From: Jeff Janes Date: Monday, November 4, 2019 at 3:32 PM To: Scott Rankin Cc: "pgsql-performance@lists.postgresql.org"

Re: Huge shared hit for small table

Thanks to Justin for the clarification around pgstatindex: Staging: version2 tree_level1 index_size425984 root_block_no3 internal_pages1 leaf_pages50 empty_pages0 deleted_pages0 avg_leaf_density70.86 leaf_fragmentation16 Production: version2 tree_level1 index_size360448 root_block_no3 internal_

Re: Huge shared hit for small table

om: Andres Freund Date: Monday, November 4, 2019 at 2:46 PM To: Scott Rankin Cc: "pgsql-performance@lists.postgresql.org" Subject: Re: Huge shared hit for small table Hi, On 2019-11-04 19:38:40 +, Scott Rankin wrote: > In the staging environment, we get this: > > In

Huge shared hit for small table

k, and I’m not sure what to make of it. Thanks in advance for any help you can offer! Scott SCOTT RANKIN VP, Technology Motus, LLC Two Financial Center, 60 South Street, Boston, MA 02111 617.467.1900 (O) | sran...@motus.com<mailto:rcaraf...@motus.com> Follow us on LinkedIn<https://w

Re: Slow Bitmap Index Scan

ings or lazy typing. Is it unrealistic to think that we could have sub-1000ms searches against that size of a table? On 11/28/18, 2:18 PM, "Justin Pryzby" wrote: On Wed, Nov 28, 2018 at 07:08:53PM +, Scott Rankin wrote: > We recently moved our production databa

Re: Slow Bitmap Index Scan

On 11/28/18, 2:18 PM, "Justin Pryzby" wrote: On Wed, Nov 28, 2018 at 07:08:53PM +0000, Scott Rankin wrote: > We recently moved our production database systems from a 9.4 running on a self-managed EC2 instance to 9.6.10 on Amazon’s AWS (same RAM, CPU). After the move,

Slow Bitmap Index Scan

autovacuum_vacuum_threshold 50 cpu_index_tuple_cost 0 cpu_operator_cost 0 cpu_tuple_cost 0 cursor_tuple_fraction 0 effective_cache_size 12584kB effective_io_concurrency 1 gin_fuzzy_search_limit 0 gin_pending_list_limit 4MB maintenance_work_mem 4027MB seq_page_cost 1 shared_buffers 6288kB work_mem

Inconsistent query times and spiky CPU with GIN tsvector search

Hello all, We are running postgresql 9.4 and we have a table where we do some full-text searching using a GIN index on a tsvector column: CREATE TABLE public.location_search ( id bigint NOT NULL DEFAULT nextval('location_search_id_seq'::regclass), … search_field_tsvector tsvector )