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
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
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. The query is fairly
simple, with a few
chuckle 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 result. Again
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
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
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
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 postgres, what
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