Обсуждение: Re: [PERFORM] [SQL] Unanswered Questions WAS: An unresolved performance problem.

Поиск
Список
Период
Сортировка

Re: [PERFORM] [SQL] Unanswered Questions WAS: An unresolved performance problem.

От
Tom Lane
Дата:
Randall Lucas <rlucas@tercent.net> writes:
> I suspect that a good number of fairly simple questions aren't being
> answered because they're either misdirected or because the poster
> hasn't included an "answerable" question (one with sufficient
> information to answer).

That's always been a problem, but it does seem to have been getting
worse lately.

> A suggestion to partially counter this, at least for "slow query" type
> questions, has been put forth.  If we make it a social norm on the
> pg-lists in general to reply off-list to inadequately descriptive "slow
> query" questions with a canned message of helpful guidance, we may be
> able to up the level of "answerability" of most questions.

The idea of some canned guidance doesn't seem bad, but I'm not sure if
it should be off-list or not.  If newbies are corrected off-list then
other newbies who might be lurking, or reading the archives, don't learn
any better and will make the same mistakes in their turn.

How about a standard answer of "you haven't really provided enough info
for us to be helpful, please see this-URL for some hints"?  That would
avoid bulking up the list archives with many copies, yet at the same
time the archives would provide evidence of the existence of hints...

> Thoughts?  Josh and I have placed a draft at
> http://techdocs.postgresql.org/guides/SlowQueryPostingGuidelines

Looks good, though I concur with Stephan's comment that the table
schemas aren't optional.

It might be worth including a checklist of the standard kinds of errors
(for example, datatype mismatch preventing index usage).  Come to think
of it, that starts to make it look like a FAQ list directed towards
performance issues.  Maybe we could make this a subsection of the main
FAQ?

            regards, tom lane


Re: [PERFORM] [SQL] Unanswered Questions WAS: An unresolved performance problem.

От
Sean Chittenden
Дата:
> > I suspect that a good number of fairly simple questions aren't
> > being answered because they're either misdirected or because the
> > poster hasn't included an "answerable" question (one with
> > sufficient information to answer).
>
> That's always been a problem, but it does seem to have been getting
> worse lately.

I hate to point this out, but "TIP 4" is getting a bit old and the 6
tips that we throw out to probably about 40K people about 1-200 times
a day have probably reached saturation.  Without looking at the
archives, I bet anyone a shot of good scotch that, it's probably
pretty infrequent that people don't kill -9 their postmasters.

Any chance we could flush out the TIPs at the bottom to include,
"VACUUM ANALYZE your database regularly," or "When reporting a
problem, include the output from EXPLAIN [query]," or "ANALYZE tables
before examining the output from an EXPLAIN [query]," or "Visit [url]
for a tutorial on (schemas|triggers|views)."

-sc

--
Sean Chittenden


Re: [PERFORM] [SQL] Unanswered Questions WAS: An unresolved performance problem.

От
johnnnnnn
Дата:
On Wed, May 07, 2003 at 09:57:49PM -0700, Sean Chittenden wrote:
> I hate to point this out, but "TIP 4" is getting a bit old and the 6
> tips that we throw out to probably about 40K people about 1-200
> times a day have probably reached saturation.  Without looking at
> the archives, I bet anyone a shot of good scotch that, it's probably
> pretty infrequent that people don't kill -9 their postmasters.
>
> Any chance we could flush out the TIPs at the bottom to include,
> "VACUUM ANALYZE your database regularly," or "When reporting a
> problem, include the output from EXPLAIN [query]," or "ANALYZE
> tables before examining the output from an EXPLAIN [query]," or
> "Visit [url] for a tutorial on (schemas|triggers|views)."

Better yet, have TIPs that are appropriate to the subscribed
list. -performance has different posting guidelines, things to try,
etc. than does -bugs, than does -sql (than does -hackers, than does
-interfaces, ...).

I don't know how feasible it is to separate them out, but i think it's
worth looking into.

-johnnnnnnnnnnn