Tag Info

New answers tagged

5

Just call pg_database_size(dbname) to know the size of the database. VACUUM (without the FULL clause) does not free any space, it only marks it as reusable, and thus will not change the database's size (except in a rare boundary case, see Routine Vacuuming). ANALYZE does statistical sampling and would be useful if you needed the row counts, but for the ...


1

What @Daniel explained so accurately becomes rather obvious when you add the respective column to your query: SELECT name, setting, unit, min_val, max_val, context FROM pg_settings WHERE name = 'shared_buffers'; Or just: SELECT * FROM pg_settings WHERE name = 'shared_buffers'; Consider the project guidelines for your "non-bleeding-edge" (a.k.a. ...


3

The canonical unit for shared_buffers is pages of 8kB, so the actual memory allocated in bytes is: 524288 * 8192 = 4294967296 or 4096*1024*1024 as requested. You can also check the size of the segment of memory with ipcs -m


0

You could also create the indexes on other tablespaces than the default. These tablespaces could point to disks that are not redundant (just recreate the indexes if they fail), or are on faster arrays. You might also consider partitioning the table using the same criteria as your partial indexes. This would allow for the same speed as the index when ...


1

Perfect tuning is an art and the underlying system (meaning the data and its usage patterns) is almost always evolving in ways automation can't predict or react to. Tuning is also based on past activity; the system can't predict tomorrow's growth or usage patterns, but a DBA can to some degree. We're a long way away from decent artificial intelligence and I ...


3

PAGEIOLATCH_XX waits are logged by SQL Server when it is waiting for data to be read from the disk. Index maintenance is a notoriously intensive operation and because of this it should be performed at your quietest times to avoid any impact on production. You mention you have queries that are causing the same waits. If this is at the same time as the ...


1

The first thing that I noticed is that the query plan compilation time was over 3 seconds for each query. Wow, this is a really complex query! Because the solution space of potential execution plans is so large (it grows exponentially with the number of the number of objects involved in the query), SQL Server is only going to be able to explore a tiny ...



Top 50 recent answers are included