Re: Slow query on OS X box

From: Tomasz Myrta <jasiek(at)klaster(dot)net>
To: Patrick Hatcher <PHatcher(at)macys(dot)com>
Cc: pgsql-performance(at)postgresql(dot)org
Subject: Re: Slow query on OS X box
Date: 2003-01-22 20:58:54
Message-ID: 3E2F060E.9000509@klaster.net
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-performance

Patrick Hatcher wrote:

>I have a table that contains over 13 million rows. This query takes an
>extremely long time to return. I've vacuum full, analyzed, and re-indexed
>the table. Still the results are the same. Any ideas?
>TIA
>Patrick
>
>mdc_oz=# explain analyze select wizard from search_log where wizard
>='Keyword' and sdate between '2002-12-01' and '2003-01-15';
> QUERY PLAN
>-----------------------------------------------------------------------------------------------------------------------------
> Seq Scan on search_log (cost=0.00..609015.34 rows=3305729 width=10)
>(actual time=99833.83..162951.25 rows=3280573 loops=1)
> Filter: ((wizard = 'Keyword'::character varying) AND (sdate >
>= '2002-12-01'::date) AND (sdate <= '2003-01-15'::date))
> Total runtime: 174713.25 msec
>(3 rows)
>
>My box I'm running PG on:
>Dual 500 Mac OS X
>1g ram
>Pg 7.3.0
>
>Conf settings
>max_connections = 200
>shared_buffers = 15200
>#max_fsm_relations = 100 # min 10, fsm is free space map, ~40 bytes
>#max_fsm_pages = 10000 # min 1000, fsm is free space map, ~6 bytes
>#max_locks_per_transaction = 64 # min 10
>#wal_buffers = 8 # min 4, typically 8KB each
>
>
>
>
>CREATE TABLE public.search_log (
> wizard varchar(50) NOT NULL,
> sub_wizard varchar(50),
> timestamp varchar(75),
> department int4,
> gender varchar(25),
> occasion varchar(50),
> age varchar(25),
> product_type varchar(2000),
> price_range varchar(1000),
> brand varchar(2000),
> keyword varchar(1000),
> result_count int4,
> html_count int4,
> fragrance_type varchar(50),
> frag_type varchar(50),
> frag_gender char(1),
> trip_length varchar(25),
> carry_on varchar(25),
> suiter varchar(25),
> expandable varchar(25),
> wheels varchar(25),
> style varchar(1000),
> heel_type varchar(25),
> option varchar(50),
> metal varchar(255),
> gem varchar(255),
> bra_size varchar(25),
> feature1 varchar(50),
> feature2 varchar(50),
> feature3 varchar(50),
> sdate date,
> stimestamp timestamptz,
> file_name text
>) WITH OIDS;
>
>CREATE INDEX date_idx ON search_log USING btree (sdate);
>CREATE INDEX slog_wizard_idx ON search_log USING btree (wizard);

Did you try to change theses 2 indexes into 1?
CREATE INDEX date_wizard_idx on search_log USING btree(wizard,sdate)

How selective are these fields:
- if you ask about
wizard="Keyword",
the answer is 0.1% or 5% or 50% of rows?
- if you ask about
sdate >= '2002-12-01'::date) AND (sdate <= '2003-01-15'::date)
what is the answer?

Consider creating table "wizards", and changing field "wizard" in table "search_log"
into integer field "wizardid". Searching by integer is faster than by varchar.

Regards,
Tomasz Myrta

In response to

Browse pgsql-performance by date

  From Date Subject
Next Message John Lange 2003-01-22 21:44:42 Query plan and Inheritance. Weird behavior
Previous Message Patrick Hatcher 2003-01-22 20:49:49 Re: Slow query on OS X box