Stef wrote:
On Fri, 03 Oct 2003 12:32:00 -0400
Tom Lane <[EMAIL PROTECTED]> wrote:
=> What exactly is failing? And what's the platform, anyway?
Nothing is really failing atm, except the funds for better
hardware. JBOSS and some other servers need to be
run on these machines, along with linux,
Bruce Momjian wrote:
OK, I beefed up the TODO:
* Use a fixed row count and a +/- count with MVCC visibility rules
to allow fast COUNT(*) queries with no WHERE clause(?)
I can always give the details if someone asks. It doesn't seem complex
enough for a separate TODO.detail item.
On Sun, Oct 05, 2003 at 07:32:47PM -0400, Neil Conway wrote:
> been pointed out numerous times on -hackers and in the literature, using
> LRU for a DBMS shared buffer cache is far from optimal, and better
> algorithms have been proposed (e.g. LRU-K, ARC). We could even have the
> VACUUM command in
On Sun, 2003-10-05 at 19:43, Tom Lane wrote:
> This would be relatively easy to fix as far as our own buffering is
> concerned, but the thing that's needed to make it really useful is
> to prevent caching of seqscan-read pages in the kernel disk buffers.
True.
> I don't know any portable way to d
Neil Conway <[EMAIL PROTECTED]> writes:
> ... We could even have the
> VACUUM command inform the bufmgr that the pages it is in the process of
> reading in are part of a seqscan, and so are unlikely to be needed in
> the immediate future.
This would be relatively easy to fix as far as our own buff
On Sat, 2003-10-04 at 11:22, Andrew Sullivan wrote:
> Also, a vacuum pretty much destroys your shared buffers, so you have
> to be aware of that trade-off too.
True, although there is no reason that this necessary needs to be the
case (at least, as far as the PostgreSQL shared buffer goes). As has
After a long battle with technology,[EMAIL PROTECTED] ("Matt Clark"), an earthling,
wrote:
>> The point is that a big seqscan (either VACUUM or a plain table scan)
>> hits a lot of pages, and thereby tends to fill your cache with pages
>> that aren't actually likely to get hit again soon, perhaps
> And for those GUIs, wouldn't it be 97% as good to run an ANALYZE and give the
> approximate record counts for large tables?
Interfaces which run a COUNT(*) like that are broken by design. They
fail to consider the table may really be a view which of course could
not be cached with results like
Bruce,
> OK, I beefed up the TODO:
>
> * Use a fixed row count and a +/- count with MVCC visibility rules
> to allow fast COUNT(*) queries with no WHERE clause(?)
>
> I can always give the details if someone asks. It doesn't seem complex
> enough for a separate TODO.detail item.
Hm
> Mainly 'cause it doesn't know where the dead tuples are till it's
> looked.
At this point I feel very stupid...
> Also, VACUUM is the data collector for the free space map,
> and so it is also charged with finding out how much free space exists
> on every page.
Ah, now I just feel enlightened!
"Matt Clark" <[EMAIL PROTECTED]> writes:
> OK, I had thought (wrongly it seems, as usual, but this is how we learn!)
> that a plain VACUUM did not incur a read of all pages. I still don't
> understand *why* it does, but I'll take your word for it.
Mainly 'cause it doesn't know where the dead tupl
> The point is that a big seqscan (either VACUUM or a plain table scan)
> hits a lot of pages, and thereby tends to fill your cache with pages
> that aren't actually likely to get hit again soon, perhaps pushing out
> pages that will be needed again soon. This happens at both the
> shared-buffer a
"Matt Clark" <[EMAIL PROTECTED]> writes:
> OK I'm definitely missing something here.
The point is that a big seqscan (either VACUUM or a plain table scan)
hits a lot of pages, and thereby tends to fill your cache with pages
that aren't actually likely to get hit again soon, perhaps pushing out
pag
> On Sun, Oct 05, 2003 at 12:14:24PM +0100, Matt Clark wrote:
> > more info on how it clobbers shared_buffers?
>
> Vacuum is like a seqscan. It touches everything on a table. So it
> doesn't clobber them, but that's the latest data. It's unlikely your
> buffers are big enough to hold your databa
On Sun, Oct 05, 2003 at 12:14:24PM +0100, Matt Clark wrote:
> more info on how it clobbers shared_buffers?
Vacuum is like a seqscan. It touches everything on a table. So it
doesn't clobber them, but that's the latest data. It's unlikely your
buffers are big enough to hold your database, unless
Tom Lane wrote:
> Bruce Momjian <[EMAIL PROTECTED]> writes:
> > Tom Lane wrote:
> >> I think that's not happening, conditionally or otherwise. The atomicity
> >> problems alone are sufficient reason why not, even before you look at
> >> the performance issues.
>
> > What are the atomicity problem
> On Sat, Oct 04, 2003 at 12:29:55AM +0100, Matt Clark wrote:
> > My real world experience on a *very* heavily updated OLTP type
> DB, following
> > advice from this list (thanks guys!), is that there is
> essentially zero cost
> > to going ahead and vacuuming as often as you feel like it. Go
> cr
17 matches
Mail list logo
