Hi,
CREATE INDEX mail_id_sent_idx ON mail(id,sent)
should do the trick? Of course you can only replace one of the two
scans by an index scan since there are no other conditions...
Jacques.
At 09:59 13/10/2009, Michael Schwipps wrote:
Hi,
I want to select the last contact of person via mail
Hi,
At 11:50 28/06/2005, Praveen Raja wrote:
I assume you took size to mean the row size?
Nope, the size of the table.
What I really meant was
does the number of rows a table has affect the performance of new
inserts into the table (just INSERTs) all other things remaining
constant. Sorry f
Hi,
At 01:16 28/06/2005, Karl O. Pinc wrote:
http://www.postgresql.org/docs/8.0/static/indexes-examine.html
Says:
"If you do not succeed in adjusting the costs to be more
appropriate, then you may have to resort to forcing index
usage explicitly."
Is there a way to force a query to use a part
Hi,
At 13:50 27/06/2005, Praveen Raja wrote:
Just to clear things up a bit, the scenario that I'm interested in is a
table with a large number of indexes on it (maybe 7-8).
If you're after performance you'll want to carefully consider which indexes
are really useful and/or redesign your schem
Hi,
At 13:24 27/06/2005, Praveen Raja wrote:
I'm wondering if and how the size of a table affects speed of inserts
into it? What if the table has indexes, does that alter the answer?
Many parameters will affect the result:
- whether there are any indexes (including the primary key, unique
con
Hi,
At 21:38 23/06/2005, Bricklen Anderson wrote:
Situation:
I'm trying to optimize an ETL process with many upserts (~100k aggregated
rows)
(no duplicates allowed). The source (table t2) table holds around 14 million
rows, and I'm grabbing them 100,000 rows at a time from t2, resulting in abo
Hi,
At 19:55 20/06/2005, Dan Harris wrote:
Also, I'm sure some people will respond with "turn on query
logging".. I've explored that option and the formatting of the log
file and the fact that EVERY query is logged is not what I'm after
for this project.
You can log just those queries that tak
Hi,
At 16:44 20/06/2005, Alex Stapleton wrote:
We never delete
anything (well not often, and not much) from the tables, so I am not
so worried about the VACUUM status
DELETEs are not the only reason you might need to VACUUM. UPDATEs are
important as well, if not more. Tables that are constan
Hi,
At 18:00 18/06/2005, PFC wrote:
I don't know what I'm talking about, but wouldn't mirorring be
faster
than striping for random reads like you often get on a database ? (ie. the
reads can be dispatched to any disk) ? (or course, not for writes, but if
you won't use fsync, random writ
Hi,
At 19:22 13/06/2005, Yves Vindevogel wrote:
It can't be indexes on other tables, right ?
It could be foreign keys from that table referencing other tables or
foreign keys from other tables referencing that table, especially if you
don't have the matching indexes...
Jacques.
Hi,
At 19:40 12/06/2005, Yves Vindevogel wrote:
Hi,
I'm trying to update a table that has about 600.000 records.
The update query is very simple :update mytable set pagesdesc = -
pages ;
(I use pagesdesc to avoid problems with sort that have one field in
ascending order and one in desc
Hi,
At 18:10 10/06/2005, [EMAIL PROTECTED] wrote:
tle-bu=> EXPLAIN ANALYZE SELECT file_type, file_parent_dir, file_name FROM
file_info_7;
What could the index be used for? Unless you have some WHERE or (in some
cases) ORDER BY clause, there's absolutely no need for an index, since you
are ju
Hi,
At 20:21 18/04/2005, Alex Turner wrote:
So I wonder if one could take this stripe size thing further and say
that a larger stripe size is more likely to result in requests getting
served parallized across disks which would lead to increased
performance?
Actually, it would be pretty much the opp
Hi,
At 20:16 18/04/2005, Alex Turner wrote:
So my assertion that adding more drives doesn't help is pretty
wrong... particularly with OLTP because it's always dealing with
blocks that are smaller that the stripe size.
When doing random seeks (which is what a database needs most of the time),
the n
Hi,
At 16:59 18/04/2005, Greg Stark wrote:
William Yu <[EMAIL PROTECTED]> writes:
> Using the above prices for a fixed budget for RAID-10, you could get:
>
> SATA 7200 -- 680MB per $1000
> SATA 10K -- 200MB per $1000
> SCSI 10K -- 125MB per $1000
What a lot of these analyses miss is that cheaper
Hi,
At 18:56 18/04/2005, Alex Turner wrote:
All drives are required to fill every request in all RAID levels
No, this is definitely wrong. In many cases, most drives don't actually
have the data requested, how could they handle the request?
When reading one random sector, only *one* drive out of
Hi,
Just wondering... Is Postgresql able to use data present within indexes
without looking up the table data?
To be more explicit, let's say I have table with two fields a and b. If I
have an index on (a,b) and I do a request like "SELECT b FROM table WHERE
a=x", will Postgresql use only the i
Hi,
At 20:20 28/03/2005, Patrick Hatcher wrote:
I'm experiencing extreme load issues on my machine anytime I have more than
40 users connected to the database. The majority of the users appear to be
in an idle state according TOP, but if more than3 or more queries are ran
the system slows to a cra
Hi all,
I'm preparing a set of servers which will eventually need to handle a high
volume of queries (both reads and writes, but most reads are very simple
index-based queries returning a limited set of rows, when not just one),
and I would like to optimize things as much as possible, so I have
19 matches
Mail list logo
