| From: | Ben <midfield(at)gmail(dot)com> |
|---|---|
| To: | Marcin Mańk <marcin(dot)mank(at)gmail(dot)com> |
| Cc: | Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us>, Kevin Grittner <kgrittn(at)ymail(dot)com>, bricklen <bricklen(at)gmail(dot)com>, "pgsql-performance(at)postgresql(dot)org list" <pgsql-performance(at)postgresql(dot)org> |
| Subject: | Re: incorrect row estimates for primary key join |
| Date: | 2013-06-27 03:48:16 |
| Message-ID: | 81857BFB-509B-45F5-A7CD-2716A3FFD46A@gmail.com |
| Views: | Raw Message | Whole Thread | Download mbox | Resend email |
| Thread: | |
| Lists: | pgsql-performance |
On Jun 26, 2013, at 5:22 PM, Marcin Mańk wrote:
> On Wed, Jun 26, 2013 at 2:29 AM, Ben <midfield(at)gmail(dot)com> wrote:
>
>> shouldn't an index scan definitely be fastest here? you don't need to touch the whole table or index. maybe there something i have misconfigured here?
>>
>
> How about you try increasing work_mem ? I think a hash join may be the
> best plan here, and it won't get chosen with low work_mem .
i will increase work_mem and experiment for the other queries, but the query which i was asking about in this particular question was looking up the single smallest key in the primary key index, which seems like it shouldn't need to touch more than one key, since it can just get the first one from an in-order index traversal. of course with my earlier bigtable/jointable join question increasing work_mem makes a lot of sense.
best regards, ben
| From | Date | Subject | |
|---|---|---|---|
| Next Message | Shaun Thomas | 2013-06-27 16:15:43 | Partitions not Working as Expected |
| Previous Message | Marcin Mańk | 2013-06-27 00:22:18 | Re: incorrect row estimates for primary key join |