Re: [PERFORM] Out of memory for Select query.

On Jun 29, 2008, at 10:20 PM, Nimesh Satam wrote: All, While running a Select query we get the below error: ERROR: out of memory DETAIL: Failed on request of size 192. Postgres Conf details: shared_buffers = 256000 work_mem =15 max_stack_depth = 16384 max_fsm_pages = 40 version: 8

Re: [PERFORM] Subquery WHERE IN or WHERE EXISTS faster?

On Jun 28, 2008, at 4:07 PM, Ulrich wrote: Hi, I have added a bit of dummy Data, 10 processors, 1 users, each user got around 12 processors. I have tested both queries. First of all, I was surprised that it is that fast :) Here are the results: EXPLAIN ANALYZE SELECT speed FRO

Re: [PERFORM] Subquery WHERE IN or WHERE EXISTS faster?

"Jaime Casanova" <[EMAIL PROTECTED]> writes: > i've made some queries run faster using EXISTS instead of large IN > clauses... actually, it was NOT EXISTS replacing a NOT IN That's just about entirely unrelated ... regards, tom lane -- Sent via pgsql-performance mailing

Re: [PERFORM] Subquery WHERE IN or WHERE EXISTS faster?

On Sat, Jun 28, 2008 at 10:53 AM, Tom Lane <[EMAIL PROTECTED]> wrote: > Ulrich <[EMAIL PROTECTED]> writes: >> People say that [EXISTS is faster] > > People who say that are not reliable authorities, at least as far as > Postgres is concerned. But it is always a bad idea to extrapolate > results on

[PERFORM] Out of memory for Select query.

All, While running a Select query we get the below error: ERROR: out of memory DETAIL: Failed on request of size 192. Postgres Conf details: shared_buffers = 256000 work_mem =15 max_stack_depth = 16384 max_fsm_pages = 40 version: 8.1.3 We are using 8gb of Primary memory for the server

Re: [PERFORM] sequence scan problem

John Beaver <[EMAIL PROTECTED]> writes: > Can anyone explain this? There should only ever be a maximum of about 50 > rows returned when the query is executed. Is the estimate that 197899 rows of gene_prediction_view have go_term_ref = 2 about right? If not, then we need to talk about fixing your

Re: [PERFORM] sequence scan problem

Oh, and the version is 8.3.3. Jeremy Harris wrote: John Beaver wrote: I'm having a strange problem with a query. The query is fairly simple, with a few constants and two joins. All relevant columns should be indexed, and I'm pretty sure there aren't any type conversion issues. But the query p

Re: [PERFORM] sequence scan problem

Jeremy Harris wrote: John Beaver wrote: I'm having a strange problem with a query. The query is fairly simple, with a few constants and two joins. All relevant columns should be indexed, and I'm pretty sure there aren't any type conversion issues. But the query plan includes a fairly heavy s

Re: [PERFORM] sequence scan problem

John Beaver wrote: I'm having a strange problem with a query. The query is fairly simple, with a few constants and two joins. All relevant columns should be indexed, and I'm pretty sure there aren't any type conversion issues. But the query plan includes a fairly heavy seq scan. The only possib

[PERFORM] sequence scan problem

I'm having a strange problem with a query. The query is fairly simple, with a few constants and two joins. All relevant columns should be indexed, and I'm pretty sure there aren't any type conversion issues. But the query plan includes a fairly heavy seq scan. The only possible complication is

Re: [PERFORM] Sources of information about sizing of hardwares to run PostgreSQL

On Fri, 27 Jun 2008, Sérgio R F Oliveira wrote: I need to specify servers and storage to run PostgreSQL. Does anyone know any source of information (articles, presentations, books, etc.) which describes methods of hardware sizing for running a large PostgreSLQ installation? There aren't any, j

Re: [PERFORM] A guide/tutorial to performance monitoring and tuning

On Fri, 27 Jun 2008, Nikhil G. Daddikar wrote: I have been searching on the net on how to tune and monitor performance of my postgresql server but not met with success. A lot of information is vague and most often then not the answer is "it depends". That's because it does depend. I collect

Re: [PERFORM] Subquery WHERE IN or WHERE EXISTS faster?

"Ulrich" <[EMAIL PROTECTED]> writes: > Hi, > Yes that looks strange. But it is not possible that I have processors in > "users_processors" which do not appear in "processors", because > "users_processors" contains foreign keys to "processors". > > If I remove the LIMIT 10 OFFSET 1 the line "Sort (

Re: [PERFORM] Subquery WHERE IN or WHERE EXISTS faster?

Hi, Yes that looks strange. But it is not possible that I have processors in "users_processors" which do not appear in "processors", because "users_processors" contains foreign keys to "processors". If I remove the LIMIT 10 OFFSET 1 the line "Sort (cost= rows=11.." disappears and the quer