"Ramy M.Hassan" <[EMAIL PROTECTED]> writes:
> I was wondering how index access methods reclaim the free disk pages after
> they are no longer used.
Btree and hash can both recycle unused pages, though neither is very
good about physically shrinking the file (neither can move existing
pages for in
Tom Lane <[EMAIL PROTECTED]> writes:
> Suppose that you run a checkpoint every 5 minutes, and with the knob
> you slow down the checkpoint to extend over say 3 minutes on average,
> rather than the normal blast-it-out-as-fast-as-possible. Then you'll
> be keeping an average of 8 minutes worth of
I was wondering how index access methods reclaim the free disk pages after
they are no longer used.
I noticed that only btree access method uses the free space map. I couldn't
find in the source code of gist special handling for free pages ( like
maintaining a free list ). Does that mean that GiST
Bruce Momjian writes:
> Greg Stark wrote:
>> Put another way, we already have such a clock scan, it's called checkpoint.
>> You could have checkpoint delay between each page write long enough to spread
>> the checkpoint i/o out over a configurable amount of time -- say half the
>> checkpoint inter
Greg Stark wrote:
>
> Tom Lane <[EMAIL PROTECTED]> writes:
>
> > Maybe we need a hybrid approach: clean a few percent of the LRU end of
> > the ARC list in order to keep backends from blocking on writes, plus run
> > a clock scan to keep checkpoints from having to do much.
>
> Well if you just
Rod Taylor <[EMAIL PROTECTED]> writes:
> It seems that with more than a few thousand structures in pg_class, tab
> completion seems to take quite a long time in the en_US locale.
> Simply switching the where clauses around gets a substantial performance
> increase.
Hm. There's no guarantee that
Le 21 déc. 04, à 06:45, Bruce Momjian a écrit :
Rémi Zara wrote:
Le 16 d?c. 04, ? 22:48, Bruce Momjian a ?crit :
I am confused by the threading failure. I don't see any free() call
in
thread_test.c. Would you go to the tools/thread directory and run
the
program manually and use a debugger to s
On Thu, Dec 23, 2004 at 10:01:33AM -0500, Tom Lane wrote:
> [EMAIL PROTECTED] writes:
> > Doing some tests I've found out that the returned value from the
> > JOINSEL is applied to REL1.rows X REL2.rows, but REL1 and REL2
> > are not 'base' table, rather relations with a number of
> > rows once ag
On Thu, Dec 23, 2004 at 10:13:03AM -0500, Tom Lane wrote:
> [EMAIL PROTECTED] writes:
> > On Thu, Dec 23, 2004 at 10:01:33AM -0500, Tom Lane wrote:
> >> Right. This amounts to assuming that the join conditions and the
> >> restriction conditions are independent, which of course is bogus,
> >> but
On Thu, Dec 16, 2004 at 01:56:29PM -0500, Tom Lane wrote:
> "Mark Cave-Ayland" <[EMAIL PROTECTED]> writes:
> > ... But in the case of
> > , if we're estimating the number of rows to return then
> > that becomes harder
>
> I didn't say it was easy ;-). The existing selectivity functions can't
>
Mark,
I looked at the *known* supported platforms list and noticed that Suse 9.1
was not on the list. We have been running 8.0 beta, RC1, and RC2 for
several months and we have had no problems.
Just an FYI
Thanks
===
Steve Howie
Database Programmer
--
It seems that with more than a few thousand structures in pg_class, tab
completion seems to take quite a long time in the en_US locale.
Simply switching the where clauses around gets a substantial performance
increase. Using an index would be even better, but it remains unused due
to the "pattern
On Mon, Dec 20, 2004 at 11:20:46PM -0500, Tom Lane wrote:
> Bruce Momjian writes:
> > Tom Lane wrote:
> >> Exactly. But 1% would be uselessly small with this definition. Offhand
> >> I'd think something like 50% might be a starting point; maybe even more.
> >> What that says is that a page isn't
Sibtay Abbas wrote:
i never happen to read this rule when i signed up to
this mailing list...so if you ve made up a rule by
urself for this mailing list just do us a favor by
officially announcing it
Got a question ...?
http://www.catb.org/~esr/faqs/smart-questions.html
Andre
--
14 matches
Mail list logo