On Thu, Oct 28, 2004 at 07:49:28PM -0400, Tom Lane wrote:
> "Jim C. Nasby" <[EMAIL PROTECTED]> writes:
> > On Sun, Oct 24, 2004 at 04:11:53PM -0400, Tom Lane wrote:
> >> The test case you are showing is probably suffering from nonrandom
> >> placement of this particular data value; which is somethi
"Jim C. Nasby" <[EMAIL PROTECTED]> writes:
> On Sun, Oct 24, 2004 at 04:11:53PM -0400, Tom Lane wrote:
>> The test case you are showing is probably suffering from nonrandom
>> placement of this particular data value; which is something that the
>> statistics we keep are too crude to detect.
> Isn
On Sun, Oct 24, 2004 at 04:11:53PM -0400, Tom Lane wrote:
> But the LIMIT will cut the cost of the seqscan case too. Given the
> numbers you posit above, about one row in five will have 'myval', so a
> seqscan can reasonably expect to hit the first matching row in the first
> page of the table. T
Rod Taylor <[EMAIL PROTECTED]> writes:
> On Thu, 2004-10-28 at 12:31, Tom Lane wrote:
>> Should be pretty much a fixed cost: one kernel call per table.
> Is this something that the bgwriter could periodically do and share the
> data?
I think a kernel call would be cheaper.
On Thu, 2004-10-28 at 12:31, Tom Lane wrote:
> Josh Berkus <[EMAIL PROTECTED]> writes:
> >> One drawback to this is that it would require an additional lseek per table
> >> while planning, but that doesn't seem like a huge penalty.
>
> > Hmmm ... would the additional lseek take longer for larger t
Josh Berkus <[EMAIL PROTECTED]> writes:
>> One drawback to this is that it would require an additional lseek per table
>> while planning, but that doesn't seem like a huge penalty.
> Hmmm ... would the additional lseek take longer for larger tables, or would it
> be a fixed cost?
Should be pret
Tom,
> One drawback to this is that it would require an additional lseek per table
> while planning, but that doesn't seem like a huge penalty.
Hmmm ... would the additional lseek take longer for larger tables, or would it
be a fixed cost?
--
Josh Berkus
Aglio Database Solutions
San Francisco
I would like to thank everyone for their timely
suggestions.
The problem appears to be resolved now. We
verified/modified - locking/indexes/vacuum/checkpoints/IO bottleneck/queries,
etc.
Couple significant changes were the number
of checkpoint segments were increased, and we moved
Jaime Casanova wrote:
[...]
In http://www.postgresql.org/docs/faqs/FAQ.html under
"4.8) My queries are slow or don't make use of the
indexes. Why?" says:
"However, LIMIT combined with ORDER BY often will use
an index because only a small portion of the table is
returned. In fact, though MAX() and
This topic probably available in 8.x will be very usefull for people just
using postgresql as a "normal" Database user.
-Original Message-
From: [EMAIL PROTECTED]
[mailto:[EMAIL PROTECTED] On Behalf Of Tom Lane
Sent: jeudi 21 octobre 2004 23:53
To: Thomas F.O'Connell
Cc: PgSQL - Performanc
10 matches
Mail list logo
