On Tue, Aug 23, 2005 at 13:41:32 +1000,
Lenard, Rohan (Rohan) [EMAIL PROTECTED] wrote:
I've read that indexes aren't used for COUNT(*) and I've noticed (7.3.x)
with EXPLAIN that indexes never seem to be used on empty tables - is
there any reason to have indexes on empty tables, or will
tobbe wrote:
Hi Chris.
Thanks for the answer.
Sorry that i was a bit unclear.
1) We update around 20.000 posts per night.
2) What i meant was that we suspect that the DBMS called PervasiveSQL
that we are using today is much to small. That's why we're looking for
alternatives.
Today we base
On Cum, 2005-08-26 at 19:31 -0400, Tom Lane wrote:
I think the problem is that the planner is underestimating the cost of
evaluating this complicated filter condition:
- Seq Scan on scf_irsaliye irs (cost=0.00..30.00 rows=1
width=20) (actual time=0.290..0.290 rows=0
On Fri, Aug 26, 2005 at 07:31:51PM -0400, Tom Lane wrote:
Or you could just play with the order of the filter conditions ... for
example, the date condition at the end is probably far cheaper to test
than the text comparisons, so if that's fairly selective it'd be worth
putting it first.
On 27-8-2005 0:56, Tom Lane wrote:
Arjen van der Meijden [EMAIL PROTECTED] writes:
As said, it chooses sequential scans or the wrong index plans over a
perfectly good plan that is just not selected when the parameters are
too well tuned or sequential scanning of the table is allowed.
I
Arjen van der Meijden [EMAIL PROTECTED] writes:
But appareantly there is a bug in the explain mechanism of the 8.1devel
I'm using (I downloaded a nightly 25 august somewhere in the morning
(CEST)), since it returned:
ERROR: bogus varno: 9
Yeah, someone else sent in a test case for this
At 10:27 AM 8/27/2005, Tom Lane wrote:
Arjen van der Meijden [EMAIL PROTECTED] writes:
But appareantly there is a bug in the explain mechanism of the 8.1devel
I'm using (I downloaded a nightly 25 august somewhere in the morning
(CEST)), since it returned:
ERROR: bogus varno: 9
Yeah,
On Sat, Aug 27, 2005 at 11:05:01AM -0400, Tom Lane wrote:
It could, but it doesn't really have enough information. We don't
currently have any model that some operators are more expensive than
others. IIRC the only sort of reordering the current code will do
in a filter condition list is to
Steinar H. Gunderson [EMAIL PROTECTED] writes:
On Sat, Aug 27, 2005 at 11:05:01AM -0400, Tom Lane wrote:
It could, but it doesn't really have enough information. We don't
currently have any model that some operators are more expensive than
others. IIRC the only sort of reordering the current
Steinar H. Gunderson [EMAIL PROTECTED] writes:
On Fri, Aug 26, 2005 at 07:31:51PM -0400, Tom Lane wrote:
Or you could just play with the order of the filter conditions ... for
example, the date condition at the end is probably far cheaper to test
than the text comparisons, so if that's fairly
Mark Kirkwood [EMAIL PROTECTED] writes:
joinlimit=# EXPLAIN SELECT c.id FROM c JOIN b ON c_id=c.id GROUP BY
c.id ORDER BY c.id DESC LIMIT 5;
[ fails to pick an available index-scan-backward plan ]
I looked into this and found that indeed the desirable join plan was
getting generated, but it
Tom Lane wrote:
I looked into this and found that indeed the desirable join plan was
getting generated, but it wasn't picked because query_planner didn't
have an accurate idea of how much of the join needed to be scanned to
satisfy the GROUP BY step. I've committed some changes that hopefully
[Tom Lane]
I looked into this and (...) I've committed some changes that hopefully will
let 8.1 be smarter about GROUP BY ... LIMIT queries.
[Mark Kirkwood]
Very nice :-)
(...)
This is 8.1devel from today.
Splendid :-) Unfortunately we will not be upgrading for some monthes still,
but anyway
13 matches
Mail list logo
