Re: *** PROBABLY SPAM *** [PERFORM] Does the psql executable support a "fetch many" approach when dumping large queries to stdout?

That makes sense. I'll just use a COPY statement instead like Hannu suggests. Pierre C wrote: Does the psql executable have any ability to do a "fetch many", using a server-side named cursor, when returning results? It seems like it tries to retrieve the query entirely to local mem

Re: [PERFORM] Does the psql executable support a "fetch many" approach when dumping large queries to stdout?

Ah, you're right. Thanks Hannu, that's a good solution. Hannu Krosing wrote: On Fri, 2010-04-02 at 16:28 -0400, Beaver, John E wrote: ... I know that the query used here could have been a COPY statement, which I assume would be better-behaved, but I'm more concerned about the ca

Re: [PERFORM] sequence scan problem

You're right - for some reason I was looking at the (18 rows) at the bottom. Pilot error indeed - I'll have to figure out what's going on with my data. Thanks! Tom Lane wrote: John Beaver <[EMAIL PROTECTED]> writes: Ok, here's the explain analyze resul

Re: [PERFORM] sequence scan problem

-> Seq Scan on functional_linkage_scores fls (cost=0.00..3928457.08 rows=232365808 width=20) (actual time=14.221..86455.902 rows=232241678 loops=1) Total runtime: 24183346.271 ms (18 rows) Jeremy Harris wrote: John Beaver wrote: I'm having a strange problem with a query. T

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

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

[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

[PERFORM] PgPool parallel query performance rules of thumb

Hi, I'm trying to make use of a cluster of 40 nodes that my group has, and I'm curious if anyone has experience with PgPool's parallel query mode. Under what circumstances could I expect the most benefit from query parallelization as implemented by PgPool? -- Sent via pgsql-performance mai

Re: [PERFORM] large tables and simple "= constant" queries using indexes

er in a few hours to see if it affects anything cache-wise. Gaetano Mendola wrote: John Beaver wrote: - Trying the same constant a second time gave an instantaneous result, I'm guessing because of query/result caching. AFAIK no query/result caching is in place in post

Re: [PERFORM] large tables and simple "= constant" queries using indexes

Thanks a lot, all of you - this is excellent advice. With the data clustered and statistics at a more reasonable value of 100, it now reproducibly takes even less time - 20-57 ms per query. After reading the section on "Statistics Used By the Planner" in the manual, I was a little concerned th

[PERFORM] large tables and simple "= constant" queries using indexes

Hi, I've started my first project with Postgres (after several years of using Mysql), and I'm having an odd performance problem that I was hoping someone might be able to explain the cause of. My query - select count(*) from gene_prediction_view where gene_ref = 523 - takes 26 sec