Re: [PERFORM] Optimizer misconfigured ?

2005-10-14 Thread Nörder-Tuitje , Marcus
Hi, meanwhile I have received the hint to make postgres use the index via SET ENABLE_SEQSCAN=FALSE; which fits perfectly. The execution plan now indicates full use of index. Nevertheless this is merely a workaround. Maybe the io-costs are configured to cheap. thanks :-) -Ursprüngliche

Re: [PERFORM] Optimizer misconfigured ?

2005-10-14 Thread Richard Huxton
Nörder-Tuitje wrote: Hi, meanwhile I have received the hint to make postgres use the index via SET ENABLE_SEQSCAN=FALSE; which fits perfectly. The execution plan now indicates full use of index. What execution plan? I still only see one message on the list. Nevertheless this is merely a

[PERFORM] Best way to get all different values in a column

2005-10-14 Thread ext-christian.roche
Ok, since my question got no answer on the general list, I'm reposting it here since this list seems in fact better suited to it. Does anyone here know what is the most efficient way to list all different values of a given column with low cardinality ? For instance I have a table with

Re: [PERFORM] Best way to get all different values in a column

2005-10-14 Thread mark
On Fri, Oct 14, 2005 at 06:02:56PM +0200, [EMAIL PROTECTED] wrote: Does anyone here know what is the most efficient way to list all different values of a given column with low cardinality ? For instance I have a table with columns DAY, NAME, ID, etc. The table is updated about each week

Re: [PERFORM] Best way to get all different values in a column

2005-10-14 Thread Steve Atkins
On Fri, Oct 14, 2005 at 06:02:56PM +0200, [EMAIL PROTECTED] wrote: Ok, since my question got no answer on the general list, I'm reposting it here since this list seems in fact better suited to it. Does anyone here know what is the most efficient way to list all different values of a

[PERFORM] Sequential scan on FK join

2005-10-14 Thread Martin Nickel
All, I can see why the query below is slow. The lead table is 34 million rows, and a sequential scan always takes 3+ minutes. Mailing_id is the PK for mailing and is constrained as a foreign key (NULLS allowed) in lead. There is an index on lead.mailing_id. I've just run VACUUM ANALYZE on