Josh Berkus wrote:
See above. Also keep in mind that PostgreSQL's use of I/O should improve
100% in version 7.5.
Really? What happened?
---(end of broadcast)---
TIP 2: you can get off all lists at once with the unregister command
(send
explain
SELECT COUNT(u.ukey) FROM u, d WHERE d.ukey = u.ukey AND u.pkey = 260
AND (u.status = 3 ) AND NOT u.boolfield ;
QUERY PLAN
--
Aggregate
Richard Huxton wrote:
On Thursday 18 March 2004 21:21, Joseph Shraibman wrote:
explain
SELECT COUNT(u.ukey) FROM u, d WHERE d.ukey = u.ukey AND u.pkey = 260
AND (u.status = 3 OR d.status = 3 ) AND NOT u.boolfield ;
QUERY PLAN
Tom Lane wrote:
Joseph Shraibman [EMAIL PROTECTED] writes:
No, pkey is not the primary key in this case. The number of entries in u
that have pkey 260 and not boolfield is 344706.
... and every one of those rows *must* be included in the join input,
*If* you use one big join in the first place
Stephan Szabo wrote:
On Mon, 22 Mar 2004, Joseph Shraibman wrote:
Tom Lane wrote:
Joseph Shraibman [EMAIL PROTECTED] writes:
No, pkey is not the primary key in this case. The number of entries in u
that have pkey 260 and not boolfield is 344706.
... and every one of those rows *must
I'm going to ask because someone else surely will:
Do you regularily vacuum/analyze the database?
Woody Woodring wrote:
Hello,
I am using postgres 7.4.2 as a backend for geocode data for a mapping
application. My question is why can't I get a consistent use of my indexes
during a query, I tend
scott.marlowe wrote:
I think you might be interested in materialized views. You could create
this as a materialized view which should be very fast to just select *
from.
That seems to be the count table I envisioned. It just hides the
details for me. It still has the problems of an extra
Tom Lane wrote:
Joseph Shraibman [EMAIL PROTECTED] writes:
I have a table that is never updated, only INSERTED into. Is there a way
I can prevent vacuum wasting time on this table
What makes you think vacuum is wasting much time on this table? AFAICS
it will only update any unfixed hint bits
I have a big table with some int fields. I frequently need to do
queries like:
SELECT if2, count(*) FROM table WHERE if1 = 20 GROUP BY if2;
The problem is that this is slow and frequently requires a seqscan. I'd
like to cache the results in a second table and update the counts with
triggers,
How does the analyzer/planner deal with rows clustered together? Does
it just assume that if this col is clustered on then the actual data
will be clustered? What if the data in the table happens to be close
together because it was inserted together originally?
Joseph Shraibman wrote:
I have a table that is never updated, only INSERTED into. Is there a way
I can prevent vacuum wasting time on this table besides vacuuming each
table in the db by itself and omitting this table?
How feasable would it be to have a marker somewhere in pg that is
updated
Use the text_pattern_ops operator when creating the index, see:
http://www.postgresql.org/docs/7.4/static/indexes-opclass.html
Michael Ryan S. Puncia wrote:
Sorry .. I am a newbie and I don't know :(
How can I know that I am in C locale ?
How can I change my database to use C locale?
See http://kerneltrap.org/node/view/3148, about 40% down, under the
header 2.6 -aa patchset, object-based reverse mapping. Does this mean
that the more shared memory the bigger the potential for a swap storm?
---(end of broadcast)---
TIP 6: Have
Neil Conway wrote:
PostgreSQL ( 7.5) won't consider using an indexscan when the predicate
involves an integer literal and the column datatype is int2 or int8.
Is this fixed for 7.5? It isn't checked off on the TODO list at
http://developer.postgresql.org/todo.php
---(end
Tom Lane wrote:
: * JDBC
With JDBC out of the core, I'm not sure why we still have a JDBC section
in the core TODO.
Speaking of which why is the jdbc site so hard to find? For that matter
the new foundry can only be found through the news article on the front
page.
Here is my query, that returns one row:
SELECT f1, f2,(SELECT dfield FROM d WHERE d.ukey = f1) FROM m WHERE
status IN(2) AND jid IN(17674) ORDER BY pkey DESC LIMIT 25 OFFSET 0;
Here was the really bad plan chosen. This didn't come back for a long
while and had to be cancelled:
On 04/27/2011 04:32 PM, Robert Haas wrote:
In the first case, PostgreSQL evidently thinks that using the indexes
will be slower than just ignoring them. You could find out whether
it's right by trying it with enable_seqscan=off.
My point is that this is just a problem with inherited tables.
17 matches
Mail list logo
