| From: | Robert Haas <robertmhaas(at)gmail(dot)com> |
|---|---|
| To: | Faheem Mitha <faheem(at)email(dot)unc(dot)edu> |
| Cc: | Eliot Gable <egable+pgsql-performance(at)gmail(dot)com>, Kevin Grittner <Kevin(dot)Grittner(at)wicourts(dot)gov>, pgsql-performance(at)postgresql(dot)org |
| Subject: | Re: experiments in query optimization |
| Date: | 2010-04-01 18:50:59 |
| Message-ID: | w2q603c8f071004011150h4bf8c5bs2b00041b51b0bb49@mail.gmail.com |
| Views: | Whole Thread | Raw Message | Download mbox | Resend email |
| Thread: | |
| Lists: | pgsql-performance |
On Thu, Apr 1, 2010 at 2:15 PM, Faheem Mitha <faheem(at)email(dot)unc(dot)edu> wrote:
> I had set the foreign keys in question (on the geno table) to be primary
> keys. This is because this setup is basically a glorified spreadsheet, and I
> don't want more than one cell corresponding to a particular tuple of
> idlink.id and anno.id (the conceptual rows and cols). Since a primary key
> defines an index, I thought putting indexes on idlink_id and anno_id was
> redundant. However, it looks like (unsurprisingly) the index corresponding
> to the primary key is across both columns, which may not be what is wanted
> for the aforesaid join
Actually it is what is wanted - that is good.
> So, should I add indexes on the individual foreign key cols idlink_id
> and anno_id after all?
I doubt that would help.
The bottom line may be that you're dealing with hundreds of millions
of rows here, so things are going to take a long time. Of course you
can always get more/faster memory, a bigger I/O subsystem, faster
processors... and it could be that with detailed study there are
optimizations that could be done even without spending money, but I
think I'm about tapped out on what I can do over an Internet mailing
list.
...Robert
| From | Date | Subject | |
|---|---|---|---|
| Next Message | Faheem Mitha | 2010-04-01 19:01:09 | Re: experiments in query optimization |
| Previous Message | Faheem Mitha | 2010-04-01 18:15:13 | Re: experiments in query optimization |