Re: [PERFORM] Improving performance on system catalog

2007-03-28 Thread chris smith
I would like to speed up this query: Total runtime: 13.844 ms Why bother? It's running in less than 14 milliseconds. -- Postgresql & php tutorials http://www.designmagick.com/ ---(end of broadcast)--- TIP 7: You can help support the Postgr

Re: [PERFORM] select with "like" from another table

2006-05-29 Thread chris smith
On 5/29/06, Anton Maksimenkov <[EMAIL PROTECTED]> wrote: Hi. I have 2 tables - one with calls numbers and another with calls codes. The structure almost like this: ... How long does this query take? SELECT code FROM a_voip_codes c, a_voip v where v.called_station_id like c.code || '%' order b

Re: [PERFORM] Worsening performance with 7.4 on flash-based system

2006-04-29 Thread chris smith
On 4/29/06, Greg Stumph <[EMAIL PROTECTED]> wrote: Well, since I got no response at all to this message, I can only assume that I've asked the question in an insufficient way, or else that no one has anything to offer on our problem. This was my first post to the list, so if there's a better way

Re: [PERFORM] Query on postgresql 7.4.2 not using index

2006-04-25 Thread chris smith
> OK. Stop and think about what you're telling postgresql to do here. > > You're telling it to cast the field group_id to int8, then compare it to > 9. How can it cast the group_id to int8 without fetching it? That's > right, you're ensuring a seq scan. You need to put the int8 cast on the > ot

Re: [PERFORM] Query on postgresql 7.4.2 not using index

2006-04-25 Thread chris smith
On 4/25/06, Arnau <[EMAIL PROTECTED]> wrote: > Hi all, > >I have the following running on postgresql version 7.4.2: > > CREATE SEQUENCE agenda_user_group_id_seq > MINVALUE 1 > MAXVALUE 9223372036854775807 > CYCLE > INCREMENT 1 > START 1; > > CREATE TABLE AGENDA_USERS_GROUPS > ( > AGENDA_USER_

Re: [PERFORM] Slow query - possible bug?

2006-04-13 Thread chris smith
On 4/13/06, Gavin Hamill <[EMAIL PROTECTED]> wrote: > laterooms=# explain analyze select allocation0_."ID" as y1_, > allocation0_."RoomID" as y2_, allocation0_."StatusID" as y4_, > allocation0_."Price" as y3_, allocation0_."Number" as y5_, > allocation0_."Date" as y6_ from "Allocation" allocation0_

Re: [PERFORM] Query using SeqScan instead of IndexScan

2006-04-01 Thread chris smith
On 4/2/06, chris smith <[EMAIL PROTECTED]> wrote: > On 4/2/06, Jim C. Nasby <[EMAIL PROTECTED]> wrote: > > On Sat, Apr 01, 2006 at 11:23:37AM +1000, chris smith wrote: > > > On 4/1/06, Brendan Duddridge <[EMAIL PROTECTED]> wrote: > > > > Hi Jim, >

Re: [PERFORM] Query using SeqScan instead of IndexScan

2006-04-01 Thread chris smith
On 4/2/06, Jim C. Nasby <[EMAIL PROTECTED]> wrote: > On Sat, Apr 01, 2006 at 11:23:37AM +1000, chris smith wrote: > > On 4/1/06, Brendan Duddridge <[EMAIL PROTECTED]> wrote: > > > Hi Jim, > > > > > > I'm not quite sure what you mean by the

Re: [PERFORM] Query using SeqScan instead of IndexScan

2006-03-31 Thread chris smith
On 4/1/06, Brendan Duddridge <[EMAIL PROTECTED]> wrote: > Hi Jim, > > I'm not quite sure what you mean by the correlation of category_id? It means how many distinct values does it have (at least that's my understanding of it ;) ). select category_id, count(*) from category_product group by catego

Re: [PERFORM] [ADMIN] syslog slowing the database?

2004-03-10 Thread Chris Smith
It might depend on how you're rotating it. Try the copy/truncate method instead of moving the log file. If you move the log file to another filename you usually have to restart the app doing the logging before it starts logging again. Chris. -Original Message- From: [EMAIL PROTECTED] [ma

Re: [PERFORM] simple query join

2004-03-08 Thread Chris Smith
ssage-From: Steven Butler [mailto:[EMAIL PROTECTED] Sent: Monday, March 08, 2004 6:12 PMTo: Chris Smith; [EMAIL PROTECTED]Subject: Re: [PERFORM] simple query join Looks to me like it's because your assetid is varchar in one table and an integer in the other table.  AFAIK, PG is

[PERFORM] simple query join

2004-03-07 Thread Chris Smith
Title: Message Hi all,   I've got what should be a relatively simple join between two tables that is taking forever and I can't work out why.   Version 7.3.4RH.   It can't be upgraded because the system is kept in sync with RedHat Enterprise (using up2date). Not my system otherwise I'd do