Enrico Weigelt wrote:
Bruno Wolff III wrote:
This gets brought up a lot. The problem is that the index doesn't include
information about whether the current transaction can see the referenced
row. Putting this information in the index will add significant overhead
to every update and the opinio
Tomeh, Husam wrote:
The other question I have. What would be the proper approach to rebuild
indexes. I re-indexes and then run vacuum/analyze. Should I not use the
re-index approach, and instead, drop the indexes, vacuum the tables, and
then create the indexes, then run analyze on tables and inde
Tweakers.net has done a database performance test between a Sun T2000 (8
core T1) and a Sun X4200 (2 dual core Opteron 280). The database
benchmark is developed inhouse and represents the average query pattern
from their website. It is MySQL centric because Tweakers.net runs on
MySQL, but Arjen va
Tim Truman wrote:
Query:
SELECT count(*) as count FROM
(
SELECT *
FROM transaction t, merchant m
WHERE t.merchant_id = m.id
AND m.id = 198
AND t.transaction_date >= '20050101'
AND t.transaction_date <= '20060925'
Ron St-Pierre wrote:
I am using postgres 7.4.1 and have a problem with a plpgsql function.
When I run the function on the production server it takes approx 33
minutes to run. I dumped the DB and copied it to a similarly configured
box and ran the function and it ran in about 10 minutes. Can anyo
Manfred Koizar wrote:
On Wed, 28 Apr 2004 09:05:04 -0400, Tom Lane <[EMAIL PROTECTED]> wrote:
[ ... visibility information in index tuples ... ]
Storing that information would at least double the overhead space used
for each index tuple. The resulting index bloat would significantly
slow index ope
Tom Lane wrote:
Manfred Koizar <[EMAIL PROTECTED]> writes:
Yes, the visible-to-all flag would be set as a by-product of an index
scan, if the heap tuple is found to be visible to all active
transactions. This update is non-critical
Oh really? I think you need to think harder about the transition
Manfred Koizar said:
>
> As Tom has explained in a nearby message his concern is that --
> unlike dead-to-all -- visible-to-all starts as false, is set to true
> at some point in time, and is eventually set to false again.
> Problems arise if one backend wants to set visible-to-all to true
> while
Vitaly Belman wrote:
If you'll be so kind though, I'd be glad if you could spot anything to
speed up in this query. Here's the query and its plan that happens
without any caching:
-
QUERY
---
