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

""Chun Yit(Chronos)"" <[EMAIL PROTECTED]> writes > >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

Re: [PERFORM] Speedier count(*)

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 defa

Re: [PERFORM] Speedier count(*)

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

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

> >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 tu

Re: [PERFORM] partial index regarded more expensive

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 d

Re: [PERFORM] Speedier count(*)

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

Re: [PERFORM] Speedier count(*)

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. h

Re: [PERFORM] Speedier count(*)

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 broadcast)---

[PERFORM] Speedier count(*)

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 dynam

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

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

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

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 si

Re: [PERFORM] partial index regarded more expensive

[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 ma

Re: [PERFORM] partial index regarded more expensive

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

[PERFORM] partial index regarded more expensive

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+delta>now() usually means state=4). There are also an insignificant numb