Tom Lane wrote:
> Jeffrey Tenny <[EMAIL PROTECTED]> writes:
>> I tried the seqscan disabling and got what sounds like the desired plan:
>> Sort (cost=54900.62..54940.29 rows=1587 width=16) (actual
time=20.208..22.138 rows=677 loops=1)
>> Sort Key: f, c
>>
re my question here: what would be the JDBC-proper technique,
my app is all jdbc.
Jeffrey Tenny wrote:
1) is there a way to enable that for a single query in a multi-query
transaction?
---(end of broadcast)---
TIP 3: Have you checked our
affect other queries in the same transaction.
Thanks for the help.
Tom Lane wrote:
Jeffrey Tenny <[EMAIL PROTECTED]> writes:
I dropped the multicolumn index 'testindex2', and a new explain analyze
looks like this:
Sort (cost=35730.71..35768.28 rows=1503 width=16) (ac
identical
query times with and without the two column index.
It appears to have ignored the other indexes completely.
Tom Lane wrote:
Jeffrey Tenny <[EMAIL PROTECTED]> writes:
Well, since I don't know the exact parameter values, just substituting
1-650 for $1-$650, I get:
Index
Mark Lewis wrote:
Doing a SELECT with a large list of variables inside an IN runs slowly
on every database we've tested. We've tested mostly in Oracle and
PostgreSQL, and both get very slow very quickly (actually Oracle refuses
to process the query at all after it gets too many bind parameters).
Well, since I don't know the exact parameter values, just substituting
1-650 for $1-$650, I get:
Index Scan using testindex2 on x (cost=0.00..34964.52 rows=1503
width=16) (actual time=0.201..968.252 rows=677 loops=1)
Filter: ((f = 1) OR (f = 2) OR (f = 3) OR (f = 4) ...
So index usage is
Why does this query take so long? (PostgreSQL 8.0.3, FC4)
Hopefully I have provided enough information below.
LOG: statement: SELECT * FROM x WHERE f IN
($1,$2,$3,$4,$5,$6,$7,$8,$9,$10,$11,$12,$13,$14,$15,$16,$17,$18,$19,$20,$21,$22,$23,$24,\
$25,$26,$27,$28,$29,$30,$31,$32,$33,$34,$35,$36,$3
(Pardon my replying two two replies at once, I only get the digest and
this was easier).
Michael Stone wrote:
[...]
Well, that's what you'd expect. But a first time 70MB fetch on a freshly
rebooted system took just as long as all secondary times. (Took over a minute
to fetch, which is too l
John A Meinel wrote:
> Well, first off, the general recommendation is probably that 7.3 is
really old, and you should try to upgrade to at least 7.4, though
recommended to 8.0.
There have been issues with each release that led me to wait.
Even now I'm waiting for some things to settle in the 8
I have a largely table-append-only application where most transactions
are read-intensive and many are read-only. The transactions may span
many tables, and in some cases might need to pull 70 MB of data out of a
couple of the larger tables.
In 7.3, I don't seem to see any file system or oth
Preferably via JDBC, but by C/C++ if necessary.
Streaming being the operative word.
Tips appreciated.
---(end of broadcast)---
TIP 2: Don't 'kill -9' the postmaster
Re: your JDBC wishes: Consider IBM Cloudscape (now Apache Derby) too,
which has an apache license. It's all pure java and it's easy to get going.
As to MySql vs Postgres: license issues aside, if you have
transactionally complex needs (multi-table updates, etc), PostgreSQL
wins hands down in
Would I be correct in assuming that the following two indexes are
completely redundant except for the fact that one complains about
uniqueness constraint violations and the other does not?
Or is there are legitimate use for having BOTH indexes?
I'm trying to figure out if it's okay to delete t
Looking for some general advice on correlated subqueries vs. joins.
Which of these plans is likely to perform better. One table is a master
record table for entities and their IDs (nv_products), the other
represents a transitive closure of parent/child relationships (for a
tree) of ID's in the
I have an integer column that is not needed for some rows in the table
(whether it is necessary is a factor of other row attributes, and it
isn't worth putting in a separate table).
What are the performance tradeoffs (storage space, query speed) of using
NULL versus a sentinel integer value?
No
I have an integer column that is not needed for some rows in the table
(whether it is necessary is a factor of other row attributes, and it
isn't worth putting in a separate table).
What are the performance tradeoffs (storage space, query speed) of using
a NULL enabled column versus a NOT-NULL col
16 matches
Mail list logo
