From: | Kevin Brown <blargity(at)gmail(dot)com> |
---|---|
To: | Mark Kirkwood <markir(at)paradise(dot)net(dot)nz> |
Cc: | pgsql-performance(at)postgresql(dot)org |
Subject: | Re: Simple Join |
Date: | 2005-12-15 07:46:06 |
Message-ID: | 200512150146.06336.blargity@gmail.com |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-performance |
On Wednesday 14 December 2005 18:36, you wrote:
> Well - that had no effect at all :-) You don't have and index on
> to_ship.ordered_product_id do you? - try adding one (ANALYZE again), and
> let use know what happens (you may want to play with SET
> enable_seqscan=off as well).
I _DO_ have an index on to_ship.ordered_product_id. It's a btree.
> And also, if you are only ever interested in paid = true and
> suspended_sub = false, then you can recreate these indexes as partials -
> e.g:
>
> CREATE INDEX paid_index ON ordered_products (paid) WHERE paid = true;
> CREATE INDEX suspended_sub_index ON ordered_products (suspended_sub)
> WHERE suspended_sub = false;
They're currently defined as individuals and I'm depending on the bitmap
indexing.
> > So what's the best way to performance wiggle this info out of the db?
> > The list of values is only about 30 tuples long out of this query, so I
> > was figuring I could trigger on insert to to_ship to place the value into
> > another table if it didn't already exist. I'd rather the writing be slow
> > than the reading.
>
> Yeah - all sort of horrible denormalizations are possible :-), hopefully
> we can get the original query to work ok, and avoid the need to add code
> or triggers to you app.
That'd be great.
From | Date | Subject | |
---|---|---|---|
Next Message | Kevin Brown | 2005-12-15 07:48:15 | Re: Simple Join |
Previous Message | Johannes Bühler | 2005-12-15 07:07:14 | effizient query with jdbc |