On 20/12/13 06:53, Shaun Thomas wrote:
On 12/17/2013 08:48 PM, Kai Sellgren wrote:
This is your select:
SELECT *
FROM Log
LEFT JOIN NewsArticle ON NewsArticle.id = Log.targetId AND
Log.targetType = 'NewsArticle'
ORDER BY Log.createdAt DESC
LIMIT 10
This is your index:
CREATE INDEX
Hi,
I'm new to PostgreSQL and trying to run this query:
SELECT *
FROM Log
LEFT JOIN NewsArticle ON NewsArticle.id = Log.targetId AND
Log.targetType = 'NewsArticle'
ORDER BY Log.createdAt DESC
LIMIT 10
Basically I'm finding the last 10 log entries, which point (targetType) to
news articles.
The
On 12/17/2013 08:48 PM, Kai Sellgren wrote:
This is your select:
SELECT *
FROM Log
LEFT JOIN NewsArticle ON NewsArticle.id = Log.targetId AND
Log.targetType = 'NewsArticle'
ORDER BY Log.createdAt DESC
LIMIT 10
This is your index:
CREATE INDEX Log_targetId_targetType_idx
ON Log
USING
I've currently got this table:
,
| n=# \d nanpa
| Table public.nanpa
|Column | Type | Modifiers
| +--+---
| state | character(2) |
| npa| character(3) | not null
| nxx| character(3) | not null
| ocn|
Have you run vacuum/analyze on the table?
--
Husam
-Original Message-
From: [EMAIL PROTECTED]
[mailto:[EMAIL PROTECTED] On Behalf Of James Cloos
Sent: Wednesday, December 13, 2006 10:48 AM
To: pgsql-performance@postgresql.org
Subject: [PERFORM] Optimizing a query
I've currently got
James Cloos [EMAIL PROTECTED] writes:
... and was doing queries of the form:
| select * from nanpa where npa=775 and nxx=413;
If those are char(3) columns, shouldn't you be quoting the constants?
select * from nanpa where npa='775' and nxx='413';
Any non-numeric input will fail entirely
Husam == Tomeh, Husam [EMAIL PROTECTED] writes:
Husam Have you run vacuum/analyze on the table?
Yes, back when I first noticed how slow it was.
It did not make any difference.
explain analyze says:
,
| n=# explain analyse select * from nanpa where npa=775 and nxx=473;
|
] Optimizing a query
Husam == Tomeh, Husam [EMAIL PROTECTED] writes:
Husam Have you run vacuum/analyze on the table?
Yes, back when I first noticed how slow it was.
It did not make any difference.
explain analyze says:
,
| n=# explain analyse select * from nanpa where npa=775 and nxx=473
Marcus,
The problem, as I understand it, is that 7.4 introduced massive
improvements in handling moderately large in() clauses, as long as they
can fit in sort_mem, and are provided by a subselect.
Also, this problem may be fixed in 7.5, when it comes out. It's a known
issue.
--
Josh
UPDATE table SET table.par = table.par + 1
WHERE table.key IN ('value1', 'value2', ... , 'value1200' )
How fast is the query alone, i.e.
SELECT * FROM table
WHERE table.key IN ('value1', 'value2', ... , 'value1200' )
Also, post the output of '\d table' and EXPLAIN ANALYZE UPDATE...
Chris
Hmm... from the 'performance' point of view, since the data comes from
a quite complex select statement, Isn't it better/quicker to have this
select replaced by a select into and creating a temporary database?
The problem, as I understand it, is that 7.4 introduced massive
improvements in
On Wed, Mar 10, 2004 at 02:02:23PM -0300, Marcus Andree S. Magalhaes wrote:
Hmm... from the 'performance' point of view, since the data comes from
a quite complex select statement, Isn't it better/quicker to have this
select replaced by a select into and creating a temporary database?
On Wed, 10 Mar 2004, Marcus Andree S. Magalhaes wrote:
Guys,
I got a Java program to tune. It connects to a 7.4.1 postgresql server
running Linux using JDBC.
The program needs to update a counter on a somewhat large number of
rows, about 1200 on a ~130k rows table. The query is
Guys,
I got a Java program to tune. It connects to a 7.4.1 postgresql server
running Linux using JDBC.
The program needs to update a counter on a somewhat large number of
rows, about 1200 on a ~130k rows table. The query is something like
the following:
UPDATE table SET table.par = table.par +
14 matches
Mail list logo
