-Original Message-
From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] Behalf Of Steven Rosenstein
Sent: Sunday, February 06, 2005 8:51 PM
To: pgsql-performance@postgresql.org
Subject: [PERFORM] Can the V7.3 EXPLAIN ANALYZE be trusted?
While working on a previous question I posed to
Hi,
What you could do is create a table containing all the fields from your SELECT,
plus a per-session unique ID. Then you can store the query results in there,
and use SELECT with OFFSET / LIMIT on that table. The WHERE clause for this
temp-results table only needs to contain the per-session
Well you just selected a whole lot more rows... What's the total number of rows
in the table?
In general, what I remember from reading on the list, is that when there's no
upper bound on a query like this, the planner is more likely to choose a seq.
scan than an index scan.
Try to give your
Hi,
Try using parametrized prepared statements, does that make a difference? Or
does PGSQL jdbc not support them in your version?
--Tim
-Original Message-
From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] Behalf Of Michael Kleiser
Sent: Wednesday, November 10, 2004 2:52 PM
To: Jeff
To what extent would your problems be solved by having a 2nd server, a replication
system (such as slony-1, but there are others), and some sort of load-balancer in
front of it? The load-balancing could be as simple as round-robin DNS server,
perhaps...
Then when you need to do maintenance
Hiya,
Looking at that list, I got the feeling that you'd want to push that PG-awareness down
into the block-io layer as well, then, so as to be able to optimise for (perhaps)
conflicting goals depending on what the app does; for the IO system to be able to read
the apps mind it needs to have
Hi,
I guess the difference is in 'severe hacking inside PG' vs. 'some unknown amount of
hacking that doesn't touch PG code'.
Hacking PG internally to handle raw devices will meet with strong resistance from
large portions of the development team. I don't expect (m)any core devs of PG will be
But he's testing with v8 beta3, so you'd expect the typecast problem not to appear?
Are all tables fully vacuumed? Should the statistics-target be raised for some
columns, perhaps? What about the config file?
--Tim
-Original Message-
From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED]
Hi,
-Original Message-
From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] Behalf Of Michael Kleiser
Sent: Tuesday, September 14, 2004 4:23 PM
To: Leeuw van der, Tim
Cc: Steinar H. Gunderson; PostgreSQL Performance List
Subject: Re: [PERFORM] Data Warehouse Reevaluation - MySQL vs Postgres
Hi,
I found bulk-insert to perform very slow, when compared to MySQL / Oracle. All inserts
were done in 1 transaction. However, mitigating factors here were:
- Application was a .Net application using ODBC drivers
- PostgreSQL 7.3 running on CYGWIN with cygipc daemon
- Probably very bad tuning
+0200, Leeuw van der, Tim wrote:
- PostgreSQL 7.3 running on CYGWIN with cygipc daemon
Isn't this doomed to kill your performance anyhow?
Yes and no, therefore I mentioned it explicitly as one of the caveats. When doing
selects I could get performance very comparable to MySQL, so I don't want
Hi,
We're now getting very much off-topic about configuration of networking, but:
- What is your OS?
- What output do you get when you type 'ping localhost' in any command-prompt?
-Original Message-
[...]
I tried to put my_ip instead of localhost in
bufmng.c and it seems to work (no
Hi,
On Aug 25, 2004, at 4:22 AM, Mark Kirkwood wrote:
select
pav1.person_id
from
person_attributes_vertical pav1
where
(pav1.attribute_id = 1
and pav1.value_id in (2,3))
or (pav1.attribute_id = 2
and pav1.value_id in (2,3))
[...]
Hi,
You asked the very same question yesterday, and I believe you got some useful answers.
Why do you post the question again?
You don't even mention your previous post, and you didn't continue the thread which
you started yesterday.
Did you try out any of the suggestions which you got
Hi,
Make
multi-column indexes, using the columns from your most typical queries, putting
the most selective columns first (ie; you don't need to make indexes with
columns in the same order as they are used in the query).
For
instance, an index on cp, effectif could likely benefit both
Cannot you do a cast in your query? Does that help with using the indexes?
-Original Message-
From: [EMAIL PROTECTED]
[mailto:[EMAIL PROTECTED] Behalf Of
[EMAIL PROTECTED]
Sent: maandag 2 augustus 2004 14:09
To: [EMAIL PROTECTED]
Subject: [PERFORM] No index usage with left join
We have
Hi All,
I think it would actually be interesting to see the performance of the Cygwin version
for these same benchmarks, then we've covered all ways to run PostgreSQL on Windows
systems. (I expect though that performance of Cygwin-PostgreSQL will improve
considerably when an updated version is
Hi Aaron,
-Original Message-
From: [EMAIL PROTECTED]
[mailto:[EMAIL PROTECTED] Behalf Of
Aaron Werman
Sent: vrijdag 2 april 2004 13:57
another thing that I have all over the place is a hierarchy:
index on grandfather_table(grandfather)
index on father_table(grandfather,
Hi,
This is not going to answer your question of course but did you already try to do this
in 2 steps?
You said that the subquery itself doesn't take very long, so perhaps you can create a
temporary table based on the subquery, then in the update do a join with the temporary
table?
This
Hi,
My personal feeling on this is, that the long time taken for the first query
is for loading all sorts of libraries, JVM startup overhead etc.
What if you first do some SELECT (whatever), on a different table, to warm
up the JVM and the database?
regards,
--Tim
THIS COMMUNICATION MAY
20 matches
Mail list logo
