[PERFORM] partial index regarded more expensive

2005-08-10 Thread Tobias Brox
So, I have a table game with a timestamp attribute 'game_end', ranging from jan-2005 to present. The game table also have an attribute state, with live games beeing in state 2, and ended games beeing in state 4 (so, game_end+deltanow() usually means state=4). There are also an insignificant

Re: [PERFORM] partial index regarded more expensive

2005-08-10 Thread PFC
why not simply create an index on (game_end, state) ? ---(end of broadcast)--- TIP 4: Have you searched our list archives? http://archives.postgresql.org

Re: [PERFORM] partial index regarded more expensive

2005-08-10 Thread Tobias Brox
[PFC - Wed at 08:15:13PM +0200] why not simply create an index on (game_end, state) ? No, the planner prefers to use the partial index (I dropped the index on game(state)). -- Tobias Brox, Nordicbet IT dept This signature has been virus scanned, and is probably safe to read. This mail

Re: [PERFORM] Planner doesn't look at LIMIT?

2005-08-10 Thread Ian Westmacott
I have a case that I though was an example of this issue, and that this patch would correct. I applied this patch to an 8.0.3 source distribution, but it didn't seem to solve my problem. In a nutshell, I have a LIMIT query where the planner seems to favor a merge join over a nested loop. I've

Re: [PERFORM] Planner doesn't look at LIMIT?

2005-08-10 Thread Tom Lane
Ian Westmacott [EMAIL PROTECTED] writes: In a nutshell, I have a LIMIT query where the planner seems to favor a merge join over a nested loop. The planner is already estimating only one row out of the join, and so the LIMIT doesn't affect its cost estimates at all. It appears to me that the

[PERFORM] Speedier count(*)

2005-08-10 Thread Dan Harris
I have a web page for my customers that shows them count of records and some min/max date ranges in each table of a database, as this is how we bill them for service. They can log in and check the counts at any time. I'd like for the counts to be as fresh as possible by keeping this

Re: [PERFORM] Speedier count(*)

2005-08-10 Thread Joshua D. Drake
Also, I am using select ... group by ... order by .. limit 1 to get the min/max since I have already been bit by the issue of min() max() being slower. This specific instance is fixed in 8.1 Sincerely, Joshua D. Drake -Dan ---(end of

Re: [PERFORM] Speedier count(*)

2005-08-10 Thread Michael Fuhr
On Wed, Aug 10, 2005 at 05:37:49PM -0600, Dan Harris wrote: Also, I am using select ... group by ... order by .. limit 1 to get the min/max since I have already been bit by the issue of min() max() being slower. PostgreSQL 8.1 will have optimizations for certain MIN and MAX queries.

Re: [PERFORM] Speedier count(*)

2005-08-10 Thread John A Meinel
Dan Harris wrote: I have a web page for my customers that shows them count of records and some min/max date ranges in each table of a database, as this is how we bill them for service. They can log in and check the counts at any time. I'd like for the counts to be as fresh as possible by

Re: [PERFORM] partial index regarded more expensive

2005-08-10 Thread Tom Lane
Tobias Brox [EMAIL PROTECTED] writes: This query puzzles me: select * from game where game_end'2005-07-30' and state in (3,4); ... Now, how can the planner believe the game_by_state-index to be better? I suspect the problem has to do with lack of cross-column statistics. The planner does

[PERFORM] it is always delete temp table will slow down the postmaster?

2005-08-10 Thread Chun Yit(Chronos)
hi, i got one situation here, i create one pl/pgsql function that using temp table to store temporary data. wherever i execute my function, i need to delete all the data inside the temp table, but this will slow down the searching function if i conitnue to run the server because old

Re: [PERFORM] Speedier count(*)

2005-08-10 Thread Gavin Sherry
Hi Dan, On Wed, 10 Aug 2005, Dan Harris wrote: I have a web page for my customers that shows them count of records and some min/max date ranges in each table of a database, as this is how we bill them for service. They can log in and check the counts at any time. I'd like for the counts to

Re: [PERFORM] Speedier count(*)

2005-08-10 Thread Mark Cotner
Here's a trigger I wrote to perform essentially the same purpose. The nice thing about this is it keeps the number up to date for you, but you do incur slight overhead. CREATE TABLE test (id serial primary key, name varchar(20)); CREATE TABLE rowcount (tablename varchar(50), rowcount bigint