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
On Mon, Dec 20, 2004 at 11:20:46PM -0500, Tom Lane wrote:
Bruce Momjian pgman@candle.pha.pa.us 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
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
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
On Thu, Dec 16, 2004 at 01:56:29PM -0500, Tom Lane wrote:
Mark Cave-Ayland [EMAIL PROTECTED] writes:
... But in the case of column op
unknown constant, if we're estimating the number of rows to return then
that becomes harder
I didn't say it was easy ;-). The existing selectivity
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 we really
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 again
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
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 the
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 keep note
Bruce Momjian pgman@candle.pha.pa.us 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
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
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 WAL
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
14 matches
Mail list logo
