Re: vacuum locking

Rob,

> I have had a lot push back from the core Postgres folks on the idea of
> planner hints, which would go a long way to solve the performance
> problems we are seeing.

I can tell you that the general reaction that you'll get is "let's fix the
problems with the planner instead of giving the user a workaround." Not that
that helps people running on older versions, but it stems from a attitude of
"let's heal the illness, not the symptoms" attitude that is one of our
project's strengths.

> I presented an alternative approach: have a
> "style sheet" (Scribe, LaTex) type of solution in the postmaster,
> which can be customized by end users. That got no response so I
> assume it wasn't in line with the "Postgres way" (more below).

Or you just posted it on a bad week. I don't remember your post; how about
we try it out on Hackers again and we'll argue it out?

> running. When vacuum is running, it's going through the entire
> database, and that pretty much trashes all other queries, especially
> DSS queries. As always it is just software, and there's got to be
> 80/20 solution.

See Tom's post.

> Our new project is large, high-profile, but not as data intensive as
> the problematic one. We are willing to commit significant funding and
> effort to make Postgres faster. We are "business value" driven. That
> means we solve problems practically instead of theoretically. This
> seems to be in conflict with "the Postgres way", which seems to be
> more theoretical. Our business situation comes ahead of theories.

As always, it's a matter of balance. Our "theoretical purity" has given
PostgreSQL a reliability and recoverability level only otherwise obtainable
from Oracle for six figures. And has allowed us to build an extensability
system that lets users define their own datatypes, operators, aggregates,
etc., in a way that is not possible on *any* other database. This is what
you're up against when you suggest changes to some of the core components ...
people don't want to break what's not broken unless there are substantial,
proven gains to be made.

> My customer (who monitors this list) and I believe that our changes
> would not be accepted back into the Postgres main branch.

If you haven't posted, you don't know. A *lot* of suggestions get rejected
because the suggestor wants Tom, Bruce, Peter, Joe and Jan to do the actual
work or aren't willing to follow-through with testing and maintanence. As I
said before, *I* don't remember earlier posts from you offering patches;
perhaps it's time to try again?

--
Josh Berkus
Aglio Database Solutions
San Francisco