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
