On 9/29/16 6:11 AM, Alex Ignatov (postgrespro) wrote:
With millions of tables you have to setautovacuum_max_workers
sky-high =). We have some situation when at thousands of tables
autovacuum can’t vacuum all tables that need it. Simply it vacuums some
of most modified table and never reach o
On 9/28/16 1:11 PM, Jake Nielsen wrote:
Beautiful! After changing the random_page_cost to 1.0 the original query
went from ~3.5s to ~35ms. This is exactly the kind of insight I was
fishing for in the original post. I'll keep in mind that the query
planner is very tunable and has these sorts of ha
My Apologies , was in the wrong email/forum, please disregard my email!
From: pgsql-performance-ow...@postgresql.org
[mailto:pgsql-performance-ow...@postgresql.org] On Behalf Of Joe Proietti
Sent: Friday, September 30, 2016 8:03 AM
To: Jake Nielsen ; Tom Lane
Cc: pgsql-performance@postgresql.o
Hi,
I am relatively new to MYSQL and not really sure I am in the right forum for
this.
I have a situation which I am not understanding. I am performing a simple
query :
Select * from tableA
Where date >= ‘2016’06-01’
And date < ‘2016-07-01’
Index is on date
Query returns 6271 rows
When doing
Now I found time to investigate all proposed queries side by side. Here
are the results (warmup + multiple executions). TL;DR - Jeff's proposed
answer performs significantly faster with our data than any other
solution (both planning and execution time).
I have no real idea how PostgreSQL doe
On 29.09.2016 22:26, Jeff Janes wrote:
Well, I don't recall seeing this issue on this list before (or a few
other forums I read) while I see several other issues over and over
again. So that is why I think it is a niche issue. Perhaps I've have
seen it before and just forgotten, or have not r
