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.
Is there a reason that when executing queries the table constraints are
only checked during planning and not execution? I end up making 2 round
trips to the database to get around this.
All of these queries should produce the same output:
[local]:playpen=> explain analyze select count(*) from
When I do a query on a table with child tables on certain queries pg
uses indexes and on others it doesn't. Why does this happen? For example:
[local]:playpen=> explain analyze select * from vis where id > 10747 ;
QUERY
PLAN
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:
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.
---(e
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
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
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?
-Origin
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 UPDA
J. Andrew Rogers wrote:
Do these features make a difference? Far more than you would imagine.
On one postgres server I just upgraded, we went from a 3Ware 8x7200-RPM
RAID-10 configuration to an LSI 320-2 SCSI 3x10k RAID-5, with 256M
Is raid 5 much faster than raid 10? On a 4 disk array with 3 da
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, b
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 hin
Rod Taylor wrote:
Or even better an offset into the datatable for the earliest deleted
row, so if you have a table where you update the row shortly after
insert and then never touch it vacuum can skip most of the table
(inserts are done at the end of the table, right?)
Inserts are done at the e
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
"up
Lets say I have two columns, A and B. They are each indexed seperately.
If I do a query like:
SELECT * FROM table WHERE A = 1 AND B = 2;
postgres can only use one index.
I assume that postgres uses the index data to narrow down pages in the
table to visit when doing its search. Then it goes th
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 since last vacuum" that w
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?
---(end
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
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 *mu
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
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
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 (cost=45707.84..45
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 "unr
23 matches
Mail list logo
