Not if people read them. There's good advice there, which would probably be better in a meta FAQ but people read Meta FAQ about as much as tag wikis [citation needed]
There's also the point that Erwin thinks it's worthwhile, and he's a valuable contributor.
The postgresql-performance is well looked after by an excellent Postgres contributor, but it's just a special case of query-performance applied to a specific RDBMS.
I feel that it should be merged, and the information in the Tag Wiki moved to query-performance or other postgres tags as appropria...
As I said above, I've toleratedpostgresql-performance because it seems to add some value in the practical way it is used. I don't see any actual harm being caused by it.
I'm not particularly opposed to the merge, I'm just waiting to be convinced it's beneficial in some way.
Given that every single question that is tagged postgres-performance will also be tagged postgres, the only gain in having a separate postgres-performance tag is the ability to have a customized tag wiki.
The tag wiki itself is great, and especially in this middle paragraph, there is significan...
In case anyone is interested, and regarding an off-topic question that was posted in DBA.SE, there are companies using database management systems based on the hierarchical or the network "models" nowadays. According to the IBM IMS official site: "IMS is used by many of the top Fortune 1000 companies worldwide".
@ypercubeᵀᴹ The question title and the content was something like "Are there companies using hierarchical or network databases currently?", and the answer could have been simply "Yes". Said Q is now deleted.
I am looking here for experts' advice on how to manage updating stats for very large database approx 18 TB.
We have recently started facing performance issues and believe it is due to old stats.
Actually we have a job which runs exec sp_update stats and update with default sample rate, in our c...
the real problem with compound tagging is that they require extra aliases to make them commutative, that they reduce functionality, that they don't scale, and that they increase the barrier of entry to the network (which is a weak argument if they provided anything)
Based on your question I can think of four possible issues with statistics that could be causing the issues that you're experiencing.
1. Statistics are not automatically updated often enough.
In SQL Server 2012, statistics are updated only after 20% or more of the rows in the table have changed...
"Compute Scalar operators are different from other operators (SQL Server 2005 onward) in that the expression(s) they define are not necessarily evaluated at the position they appear in the visible execution plan; evaluation can be deferred until the result of the computation is required by a later operator."
@JoeObbish Yep. Can be a performance problem when the expression is expensive and deferral is to a point where it is executed many times. I have a SQLblog post on that. Compute Scalar in the title.
You can always delete it and undelete it later when you've figured it out. Votes well be preserved. Happy to assist if I can later when I'm on a real computer.
I am looking here for experts' advice on how to manage updating stats for very large database approx 18 TB.
We have recently started facing performance issues and believe it is due to old stats.
Actually we have a job which runs exec sp_update stats and update with default sample rate, in our c...
Based on your question I can think of four possible issues with statistics that could be causing the issues that you're experiencing.
1. Statistics are not automatically updated often enough.
In SQL Server 2012, statistics are updated only after 20% or more of the rows in the table have changed...
