Re: [PERFORM] select max(field) from table much faster with a group by clause?

--On torsdag, november 01, 2007 11.34.42 -0400 Tom Lane <[EMAIL PROTECTED]> wrote: Palle Girgensohn <[EMAIL PROTECTED]> writes: --On torsdag, november 01, 2007 11.06.57 -0400 Tom Lane <[EMAIL PROTECTED]> wrote: Um, you did re-ANALYZE the table after changing the setti

Re: [PERFORM] select max(field) from table much faster with a group by clause?

--On torsdag, november 01, 2007 09.43.39 -0400 Tom Lane <[EMAIL PROTECTED]> wrote: Palle Girgensohn <[EMAIL PROTECTED]> writes: When running select max("when") from login where userid='userid' it takes a second or two, but when adding "group by userid&

Re: [PERFORM] select max(field) from table much faster with a group by clause?

--On torsdag, november 01, 2007 11.06.57 -0400 Tom Lane <[EMAIL PROTECTED]> wrote: Palle Girgensohn <[EMAIL PROTECTED]> writes: Unfortunately, altering statistics doesn't help. I see no difference when altering the value from 10 (default) to 100, 1000 or 10. :-(

Re: [PERFORM] select max(field) from table much faster with a group by clause?

--On torsdag, november 01, 2007 09.43.39 -0400 Tom Lane <[EMAIL PROTECTED]> wrote: Palle Girgensohn <[EMAIL PROTECTED]> writes: When running select max("when") from login where userid='userid' it takes a second or two, but when adding "group by userid&

[PERFORM] select max(field) from table much faster with a group by clause?

Hi, I have a table "login" with approx 600,000 tuples, a person table with approx 10 tuples. When running select max("when") from login where userid='userid' it takes a second or two, but when adding "group by userid" the planner decides on using another plan, and it gets *much* faster.

Re: [PERFORM] single index on more than two coulumns a bad thing?

--On fredag, april 02, 2004 09.56.04 -0600 Bruno Wolff III <[EMAIL PROTECTED]> wrote: On Fri, Apr 02, 2004 at 01:00:45 +0200, Palle Girgensohn <[EMAIL PROTECTED]> wrote: Is it always bad to create index xx on yy (field1, field2, field3); I guess the problem is that the index migh

[PERFORM] single index on more than two coulumns a bad thing?

Hi, I remember reading a post ages ago, maybe from Vadim, about the fact that people creating indices on more than two columns will be the first to be put againts the wall when the revolution comes... sort of... Is it always bad to create index xx on yy (field1, field2, field3); I guess the pr

Re: [PERFORM] LIKE should use index when condition doesn't include

--On tisdag, mars 30, 2004 16.56.09 -0800 Josh Berkus <[EMAIL PROTECTED]> wrote: Palle, But what about ILIKE. It does not take advantage of indices built with lower(): Nope. If you want to use a functional index, you'll need to use the function when you call the query. ILIKE is not somehow a

Re: [PERFORM] LIKE should use index when condition doesn't include

--On tisdag, mars 30, 2004 19.16.44 -0500 Tom Lane <[EMAIL PROTECTED]> wrote: Palle Girgensohn <[EMAIL PROTECTED]> writes: Shouldn't the optimizer use indices if the like condition does not have any wildcards? I can't get excited about this; if you are depending on LI

[PERFORM] LIKE should use index when condition doesn't include wildcard

Hi, Shouldn't the optimizer use indices if the like condition does not have any wildcards? An example: girgen=# explain analyze select * from person where userid = 'girgen'; QUERY PLAN

Re: [PERFORM] advice on raid controller

Come to think of it, I guess a battery-backed cache will make fsync as fast as no fsync, right? So, the q was kinda stoopid... :-/ /Palle --On måndag, september 29, 2003 23.31.54 +0200 Palle Girgensohn <[EMAIL PROTECTED]> wrote: Stupid question, perhaps, but would a battery-backed cach

Re: [PERFORM] advice on raid controller

Stupid question, perhaps, but would a battery-backed cache make it safe to set fsync=false in postgresql.conf? /Palle --On söndag, september 28, 2003 13.07.57 +0100 Matt Clark <[EMAIL PROTECTED]> wrote: As others have mentioned, you really ought to get battery-backed cache if you're doing any

Re: [PERFORM] avoiding seqscan?

--On måndag, september 29, 2003 11.12.55 -0400 Christopher Browne <[EMAIL PROTECTED]> wrote: [EMAIL PROTECTED] (Palle Girgensohn) writes: Will that make a difference? From what I've seen, it does not make much difference, but I have seen queries speed up when rewritten explicit joi

Re: [PERFORM] avoiding seqscan?

--On måndag, september 29, 2003 15.32.31 +0200 Gaetano Mendola <[EMAIL PROTECTED]> wrote: Are not absolutelly bad but sometimes that path that you choose is not the optimal, in postgres 7.4 use the explicit join will be less limitative for the planner. Regards Gaetano Mendola Ah, OK. True! In thi

Re: [PERFORM] avoiding seqscan?

ut it, if so? Thanks, Palle --On måndag, september 29, 2003 00.54.43 +0200 Gaetano Mendola <[EMAIL PROTECTED]> wrote: Palle Girgensohn wrote: uu=# explain analyze uu-# select lower(substr(p.last_name,1,1)) as letter, count(*) uu-# FROM course c join group_data gd on (c.acti

Re: [PERFORM] avoiding seqscan?

Hi, Indeed, setting random_page_cost does the trick. Thanks! It seems to make sense to set random_page_cost to this value. Are there any drawbacks? postgresql-7.3.4 postgresql.conf: tcpip_socket = true max_connections = 100 superuser_reserved_connections = 2 # Performance # shared_buffe

[PERFORM] avoiding seqscan?

Hi! I have a SQL statement that I cannot get to use the index. postgresql insists on using a seqscan and performance is very poor. set enable_seqscan = true boost performance drastically, as you can see below. Since seqscan is not always bad, I'd rather not turn it off completely, but rather ge

[PERFORM] performance hit when joining with a view?

Hi! A performance question: I have some tables: Tabell "public.person" Kolumn | Typ| Modifierare --+--+--- userid | text | not null giver| text