| From: | Rusty Conover <rconover(at)infogears(dot)com> |
|---|---|
| To: | Ulrich <ulrich(dot)mierendorff(at)gmx(dot)net> |
| Cc: | pgsql-performance(at)postgresql(dot)org |
| Subject: | Re: Subquery WHERE IN or WHERE EXISTS faster? |
| Date: | 2008-06-30 07:44:45 |
| Message-ID: | B68AFD89-4213-4912-8108-8C41913F45CB@infogears.com |
| Views: | Raw Message | Whole Thread | Download mbox | Resend email |
| Thread: | |
| Lists: | pgsql-performance |
On Jun 30, 2008, at 1:29 AM, Ulrich wrote:
> I think it will be fast, because the "IN set", which is the result
> of "SELECT processorid FROM users_processors WHERE userid=4040", is
> limited to a maximum of ~500 processors which is not very big.
> Increasing Postgres' RAM would be difficult for me, because I am
> only running a very small server with 256MB RAM and the webserver
> also likes to use some RAM.
>
> Does Postgre cache the HASH-Table for later use? For example when
> the user reloads the website.
>
No the hash table only lives as long as the query is being executed.
If you're looking for generic caching, I'd suggest memcached may be
able to fill your needs.
Cheers,
Rusty
--
Rusty Conover
InfoGears Inc.
http://www.infogears.com
| From | Date | Subject | |
|---|---|---|---|
| Next Message | Matthew Wakeling | 2008-06-30 10:19:47 | Re: Planner should use index on a LIKE 'foo%' query |
| Previous Message | Ulrich | 2008-06-30 07:29:08 | Re: Subquery WHERE IN or WHERE EXISTS faster? |