Alexey Slynko [EMAIL PROTECTED] writes:
Any suggestions?
Fix contrib/intarray to have some selectivity estimation procedures
for its operators?
Without any way to estimate the number of rows matching the @@
condition, the optimizer can hardly be expected to guess right...
Ismail Kizir
- Original Message -
From: Stephan Szabo [EMAIL PROTECTED]
To: Ismail Kizir [EMAIL PROTECTED]
Cc: [EMAIL PROTECTED]
Sent: Monday, May 24, 2004 11:52 PM
Subject: Re: [HACKERS] Optimizer bug??
On Mon, 24 May 2004, Ismail Kizir wrote:
Hi all,
give us the result
Gaetano,
I've changed my settings as :
#fsync = true # turns forced synchronization on or off
#wal_sync_method = fsync# the default varies across platforms:
#effective_cache_size = 1000# typically 8KB each
random_page_cost = 2# units are one sequential
Ismail Kizir wrote:
Gaetano,
I've changed my settings as :
#fsync = true # turns forced synchronization on or off
#wal_sync_method = fsync# the default varies across platforms:
#effective_cache_size = 1000# typically 8KB each
random_page_cost = 2# units
Gaetano,
Hackers, what about to decrease the default values for this
quantities ?
Oh, I don't think Ismail has a bug, I think he probably just needs to tune his
database.
Ismail, join the PGSQL-PERFORMANCE mailing list and discuss this over there.
-HACKERS is not the appropriate place for
Josh Berkus wrote:
Gaetano,
Hackers, what about to decrease the default values for this
quantities ?
Oh, I don't think Ismail has a bug, I think he probably just needs to tune his
database.
I just only suggesting to decrease that values that are oversized for a modern
hardware.
Regards
Gaetano
Thanks Josh,
I'll subscribe to that group.
Regards
Ismail Kizir
- Original Message -
From: Josh Berkus [EMAIL PROTECTED]
To: [EMAIL PROTECTED]
Cc: Ismail Kizir [EMAIL PROTECTED]
Sent: Tuesday, May 25, 2004 8:34 PM
Subject: Re: [HACKERS] Optimizer bug??
Gaetano,
Hackers, what about
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
Josh Berkus wrote:
| Gaetano,
|
|
|I just only suggesting to decrease that values that are oversized for a
|
| modern
|
|hardware.
|
|
| Hey, have you had success with those settings that you suggested? I've tried
| tinkering with the relative CPU
Gaetano Mendola [EMAIL PROTECTED] writes:
I just only suggesting to decrease that values that are oversized for
a modern hardware.
I've seen no evidence saying that random_page_cost needs to be decreased
for modern hardware. Disk seek speed versus bandwidth hasn't changed
that much.
People
Ismail Kizir [EMAIL PROTECTED] writes:
I have a database of 20 tables, ~1gb total size. My biggest table contains
~270,000 newspaper article from Turkish journals. I am actually working on
fulltext search program of my own.
How much RAM does the machine have? Have you already executed the
Tom Lane wrote:
Gaetano Mendola [EMAIL PROTECTED] writes:
I just only suggesting to decrease that values that are oversized for
a modern hardware.
I've seen no evidence saying that random_page_cost needs to be decreased
for modern hardware. Disk seek speed versus bandwidth hasn't changed
that
Ismail Kizir [EMAIL PROTECTED] writes:
I am sure default values are erronous.
Perhaps they are --- for your database, on your hardware. Or perhaps
the problem is somewhere else (we know that the costing of nestloop
indexscan joins needs work, for instance). But in any case there's
a reason why
I am actually
working on fulltext search program of my own.
No need, use contrib/tsearch2
Chris
---(end of broadcast)---
TIP 1: subscribe and unsubscribe commands go to [EMAIL PROTECTED]
Ismail Kizir wrote:
Hi everybody,
1 EXPLAIN SELECT COUNT(*) AS c FROM articletbl WHERE
((mydate BETWEEN '2004-04-24' AND '2004-05-24' )
)
2 EXPLAIN SELECT COUNT(*) AS c FROM articletbl WHERE
((mydate = '2004-04-24')
)
(I ran VACUUM ANALYZE before running those)
mydate is an
-10-25;184
2002-10-24;205
2002-10-23;187
2002-10-22;194
2002-10-21;202
Ismail Kizir
- Original Message -
From: Hans-Jürgen Schönig [EMAIL PROTECTED]
To: Ismail Kizir [EMAIL PROTECTED]
Cc: [EMAIL PROTECTED]
Sent: Monday, May 24, 2004 8:17 PM
Subject: Re: [HACKERS] Optimizer bug
Ismail Kizir [EMAIL PROTECTED] writes:
Thanks Hans,
The optimizer does an indexed scan up to 20 days, and then, it decides to
make a sequential scan.
What are the results of explain analyze query for the various queries?
--
greg
---(end of
On Mon, May 24, 2004 at 08:27:01PM +0300, Ismail Kizir wrote:
The optimizer does an indexed scan up to 20 days, and then, it decides to
make a sequential scan.
But i am still not sure about the efficiency of this decision.
Huh, so what was the EXPLAIN ANALYZE of the query with BETWEEN?
--
: Alvaro Herrera [EMAIL PROTECTED]
To: Ismail Kizir [EMAIL PROTECTED]
Cc: [EMAIL PROTECTED]
Sent: Monday, May 24, 2004 9:23 PM
Subject: Re: [HACKERS] Optimizer bug??
On Mon, May 24, 2004 at 08:27:01PM +0300, Ismail Kizir wrote:
The optimizer does an indexed scan up to 20 days, and then, it decides
Ismail Kizir wrote:
Hi everybody,
1 EXPLAIN SELECT COUNT(*) AS c FROM articletbl WHERE
((mydate BETWEEN '2004-04-24' AND '2004-05-24' )
)
2 EXPLAIN SELECT COUNT(*) AS c FROM articletbl WHERE
((mydate = '2004-04-24')
)
(I ran VACUUM ANALYZE before running those)
mydate is an
Hi all,
give us the result of these queries:
SELECT COUNT(*) FROM articletbl;
268726 records, it takes 34169 ms. to compute this
SELECT COUNT(*) AS c FROM articletbl WHERE
mydate BETWEEN '2004-04-24' AND '2004-05-24';
18982 records, it takes 34249 ms. to compute this.
SELECT COUNT(*) AS
On Mon, 24 May 2004, Ismail Kizir wrote:
Hi all,
give us the result of these queries:
SELECT COUNT(*) FROM articletbl;
268726 records, it takes 34169 ms. to compute this
SELECT COUNT(*) AS c FROM articletbl WHERE
mydate BETWEEN '2004-04-24' AND '2004-05-24';
18982 records, it
Ismail Kizir wrote:
Hi all,
give us the result of these queries:
SELECT COUNT(*) FROM articletbl;
268726 records, it takes 34169 ms. to compute this
SELECT COUNT(*) AS c FROM articletbl WHERE
mydate BETWEEN '2004-04-24' AND '2004-05-24';
18982 records, it takes 34249 ms. to compute this.
22 matches
Mail list logo
