Re: [PERFORM] Speeding up Aggregates

2003-10-10 Thread Peter Childs
On Thu, 9 Oct 2003, Dror Matalon wrote: On Thu, Oct 09, 2003 at 07:07:00PM -0400, Greg Stark wrote: Dror Matalon [EMAIL PROTECTED] writes: Actually what finally sovled the problem is repeating the dtstamp last_viewed in the sub select That will at least convince the

Re: [PERFORM] Speeding up Aggregates

2003-10-10 Thread Rob Nagler
Greg Stark writes: Call it a wishlist bug. The problem is it would be a hard feature to implement properly. And none of the people paid to work on postgres by various companies seem to have this on their to-do lists. So don't expect it in the near future. We are using Postgres heavily, and we

Re: [PERFORM] Speeding up Aggregates

2003-10-10 Thread Josh Berkus
Dror, Ouch. I just double checked and you're right. Is this considered a bug, or just an implementation issue? It's an implementation issue, which may be fixed by 7.5 but not sooner. Basically, the free ability of PostgreSQL users to define their own aggregates limits our ability to define

Re: [PERFORM] Speeding up Aggregates

2003-10-10 Thread Dror Matalon
On Fri, Oct 10, 2003 at 10:32:32AM -0700, Josh Berkus wrote: Dror, Ouch. I just double checked and you're right. Is this considered a bug, or just an implementation issue? It's an implementation issue, which may be fixed by 7.5 but not sooner. Basically, the free ability of PostgreSQL

Re: [PERFORM] Speeding up Aggregates

2003-10-09 Thread Greg Stark
Dror Matalon [EMAIL PROTECTED] writes: Actually what finally sovled the problem is repeating the dtstamp last_viewed in the sub select That will at least convince the optimizer to use an index range lookup. But it still will have to scan every record that matches channel==$1, link==$2, and

Re: [PERFORM] Speeding up Aggregates

2003-10-09 Thread Dror Matalon
On Thu, Oct 09, 2003 at 07:07:00PM -0400, Greg Stark wrote: Dror Matalon [EMAIL PROTECTED] writes: Actually what finally sovled the problem is repeating the dtstamp last_viewed in the sub select That will at least convince the optimizer to use an index range lookup. But it still

Re: [PERFORM] Speeding up Aggregates

2003-10-09 Thread Bruno Wolff III
On Thu, Oct 09, 2003 at 17:44:46 -0700, Dror Matalon [EMAIL PROTECTED] wrote: How is doing order by limit 1 faster than doing max()? Seems like the optimizer will need to sort or scan the data set either way. That part didn't actually make a difference in my specific case. max() will never

Re: [PERFORM] Speeding up Aggregates

2003-10-09 Thread Greg Stark
Dror Matalon [EMAIL PROTECTED] writes: Ouch. I just double checked and you're right. Is this considered a bug, or just an implementation issue? Call it a wishlist bug. The problem is it would be a hard feature to implement properly. And none of the people paid to work on postgres by various

Re: [PERFORM] Speeding up Aggregates

2003-10-09 Thread Christopher Kings-Lynne
Say, what do people think about a comment board thing like php.net has attached to the documentation. People can add comments that show up directly on the bottom of the documentation for each function. I find it's mostly full of junk but skimming the comments often turns up one or two relevant

Re: [PERFORM] Speeding up Aggregates

2003-10-08 Thread Greg Stark
Rod Taylor [EMAIL PROTECTED] writes: On Fri, 2003-10-03 at 17:53, Dror Matalon wrote: On Fri, Oct 03, 2003 at 05:44:49PM -0400, Rod Taylor wrote: It is too bad the (channel, link) index doesn't have dtstamp at the end of it, otherwise the below query would be a gain (might be a small

Re: [PERFORM] Speeding up Aggregates

2003-10-08 Thread Dror Matalon
Actually what finally sovled the problem is repeating the dtstamp last_viewed in the sub select select articlenumber, channel, description, title, link, dtstamp from items i1, my_channels where ((i1.channel = '2' and my_channels.id = '2' and owner = 'drormata' and (dtstamp

Re: [PERFORM] Speeding up Aggregates

2003-10-03 Thread Josh Berkus
Dror, select articlenumber, channel, description, title, link, dtstamp from items, my_channels where items.channel = '2' and my_channels.id = '2' and owner = 'drormata' and dtstamp last_viewed and articlenumber not in (select item from viewed_items where channel

Re: [PERFORM] Speeding up Aggregates

2003-10-03 Thread Dror Matalon
Hi Josh, On Fri, Oct 03, 2003 at 02:07:10PM -0700, Josh Berkus wrote: Dror, select articlenumber, channel, description, title, link, dtstamp from items, my_channels where items.channel = '2' and my_channels.id = '2' and owner = 'drormata' and dtstamp last_viewed and

Re: [PERFORM] Speeding up Aggregates

2003-10-03 Thread Josh Berkus
Dror, I am using 7.4, and had tried NOT EXISTS and didn't see any improvements. It wouldn't if you're using 7.4, which has improved IN performance immensely. What happens if you stop using a function and instead use a subselect? -- -Josh Berkus Aglio Database Solutions San Francisco

Re: [PERFORM] Speeding up Aggregates

2003-10-03 Thread Rod Taylor
item_max_date() looks like this: select max(dtstamp) from items where channel = $1 and link = $2; It is too bad the (channel, link) index doesn't have dtstamp at the end of it, otherwise the below query would be a gain (might be a small one anyway). select dtstamp from items where

Re: [PERFORM] Speeding up Aggregates

2003-10-03 Thread Dror Matalon
On Fri, Oct 03, 2003 at 05:44:49PM -0400, Rod Taylor wrote: item_max_date() looks like this: select max(dtstamp) from items where channel = $1 and link = $2; It is too bad the (channel, link) index doesn't have dtstamp at the end of it, otherwise the below query would be a gain (might

Re: [PERFORM] Speeding up Aggregates

2003-10-03 Thread Dror Matalon
On Fri, Oct 03, 2003 at 02:35:46PM -0700, Josh Berkus wrote: Dror, I am using 7.4, and had tried NOT EXISTS and didn't see any improvements. It wouldn't if you're using 7.4, which has improved IN performance immensely. What happens if you stop using a function and instead use a

Re: [PERFORM] Speeding up Aggregates

2003-10-03 Thread Dror Matalon
On Fri, Oct 03, 2003 at 06:10:29PM -0400, Rod Taylor wrote: On Fri, 2003-10-03 at 17:53, Dror Matalon wrote: On Fri, Oct 03, 2003 at 05:44:49PM -0400, Rod Taylor wrote: item_max_date() looks like this: select max(dtstamp) from items where channel = $1 and link = $2; It is too

Re: [PERFORM] Speeding up Aggregates

2003-10-03 Thread Rod Taylor
I hope it isn't the first or second one ;) CREATE or REPLACE FUNCTION item_max_date (int4, varchar) RETURNS timestamptz AS ' select max(dtstamp) from items where channel = $1 and link = $2; ' LANGUAGE 'sql'; How about the below? CREATE or REPLACE FUNCTION item_max_date (int4, varchar)