4

The is well looked after by an excellent Postgres contributor, but it's just a special case of applied to a specific RDBMS.

I feel that it should be merged, and the information in the Tag Wiki moved to or other postgres tags as appropriate:

enter image description here


enter image description here

1
  • 2
    I'm trying to start a discussion, not push for my solution. Perhaps there is a great reason for the tag I haven't thought of, and if so, hopefully that will be spelled out in an answer here, so if anyone else asks we have somewhere to point them.
    – Jack Douglas Mod
    Commented Mar 4, 2017 at 10:07

3 Answers 3

Reset to default
6

Given that every single question that is tagged will also be tagged , the only gain in having a separate tag is the ability to have a customized tag wiki.

The tag wiki itself is great, and especially in this middle paragraph, there is significant Postgres-specific advice:

Consider the basic advice on Performance Optimization and Slow Query Questions in PostgreSQL Wiki before asking questions on this tag, including the "Things to try before you post" section. Using EXPLAIN is particularly important. Useful ebooks are freely available.

The down-side is that it invites fragmentation of all other tags — do we really want to go down the line of having , etc? The benefit would be the same for these cases too, namely that we could create tag wikis with Postgres-specific links and information.

Alternatively, why not just have a single 'performance' tag, and divide the tag wiki into sections for each RDBMS? All the text in the tag wiki could be transferred 'as is' into et al.

There are two bits of data we are lacking that might be helpful to have from Stack Exchange:

  1. How often is the tag wiki page visited.
  2. Which tagging system is more beneficial for search purposes.
3
  • 2
    Gawd, I hate to disagree with @Erwin ever, but you win this one. I'm also very active on postgresql. It makes far more sense to me not to go down the path of having RDBMS-specific subtags for everything. And, it's not like you can't query for it.. [postgresql]+[query-performance] is simply better. Somethings should just chance and should have never been.
    – Evan Carroll
    Commented Mar 4, 2017 at 20:21
  • 1
    Well, both of you have a point, the systematics is cleaner with separate tags, but there are drawbacks. If we cram instructions and information for 10 different RDBMS in a single tag, who will read it? People hate reading long text. I can't think of a better place to maintain that kind of information than a tag wiki. Currently, quite a few people actually read it and follow at least some instructions. Maybe a meta question with a canonical community wiki answer? Edits on tag wikis are conveniently reserved for users with reputation in the tag ...
    – Erwin Brandstetter
    Commented Mar 8, 2017 at 2:34
  • 2
    @Erwin My feeling is that Meta is the way to go — perhaps a compressed version in the tag Wiki with links to meta for each RDBMS. In practice I doubt there will be 10 sections — more like 3 or 4 at most.
    – Jack Douglas Mod
    Commented Mar 8, 2017 at 9:37
5

No action needed

Benefits of the status quo

  • The tag is relatively popular (253 questions)
  • It is actively curated and promoted by its subject area experts both here and on SO
  • The tag Excerpt and Wiki are (unusually!) useful, appropriate, and targeted to the intended usage

This tag therefore adds value to the community in the practical way it is used.

Merge drawbacks

Someone will need to review the result to:

  • Ensure the new tag is actually appropriate in each case
  • Add to the question if needed
  • Remove references (perhaps in comments) to the removed tag

We will also need to notify people with the old tag in their subscriptions and filters to change these to plus (where that is even possible).

This makes work for the subject area experts, without providing them with any compensating benefit.

It will also deprive them of a tool they explicitly created and actively use & maintain.

Conclusion

Why bother with this change?

The current tag appears useful to the people using it, and is not causing any actual harm to the site.

Making the change may inconvenience existing tag users, and require moderator time to implement.

The only benefit seems to be to eliminate a perceived technical redundancy in the tagging system.

It does not set a precedent. New tags are reviewed on their merits.

2
  • Merge drawbacks is a tactical question that has no place on whether or not the merge should happen. The rest is an argument from the status-quo which seems very weak. We should prefer the status-quo pass some intellectual rigor rather than accepting it. @Jack presented an argument for a change. And, as far as I can see your argument boils down to the change being difficult, and it being a change of some sort. Presumably, Jack will address your merge concerns and do it properly. If so, could you argue that we would be worse off a week after the change, or not?
    – Evan Carroll
    Commented Mar 4, 2017 at 20:27
  • I added this option so people had something else to vote on.
    – Paul White Mod
    Commented Feb 9, 2019 at 10:26
4

I think discussing / tuning / optimizing performance is sufficiently distinct for the various RDBMS to warrant a separate tag. We have put some thought into refining information, instructions and resources in and it serves well so far. (I say "we" because it started with the related tag on SO.)

If general performance aspects are involved, it can make sense to additionally or instead tag one or more of , , - which also serve well for RDBMS that don't have a specific (yet).

Other than that, I can subscribe to what Paul answered. The tag should stay.

0

You must log in to answer this question.

Not the answer you're looking for? Browse other questions tagged .