Hi all,
I have a relation where a tuple typically undergoes a lifecycle
something like:
1) Created
2) Updated maybe thousands of times (no updates to indexed columns though)
3) Rarely or never modified again
The following query takes about 100 minutes (3 seconds per tuple):
SELECT count(id) fr
On 2/27/2012 10:29 PM, Andy Colson wrote:
On 02/27/2012 06:55 PM, Dave Vitek wrote:
Hi all,
I have a relation where a tuple typically undergoes a lifecycle
something like:
1) Created
2) Updated maybe thousands of times (no updates to indexed columns
though)
3) Rarely or never modified
On 2/28/2012 5:21 PM, Andy Colson wrote:
On 2/28/2012 2:09 PM, Dave Vitek wrote:
The following query takes about 100 minutes (3 seconds per tuple):
SELECT count(id) from T
so table T has 18,000 rows? (100 * 60 * 3)
100 minutes * 60 (sec/min) / 3 (sec/tuple) = 2000 tuples
Well... math was
Hi all,
I have a query I'd like to speed up. I am wondering whether the query
planner is capable of coming up with a certain kind of plan for this
query, and if I might tickle it into doing so, or if I have to
explicitly use subqueries to get what I want.
Imagine we have tables A, B, and C
Hi all,
On a new x86_64 windows 7 SMP, a new database server was being set up by
some test automation. We are using official 8.4.2 binaries.
It runs:
initdb -D c:\... --no-locale
... eventually this outputs the "Success. You can now start the database
server using ..." message. Once that e
Hi again,
I'm going to answer my own question. I think there is a race where two
database servers are being setup on the same port at the same time and
two different tests end up trying to create the same DB on the same
server at the same time.
Let me know if you think I'm wrong
Hi all,
Yesterday I ran into two backend crashes and then an autovacuum launcher
process crash. The autovacuum log was:
LOG: database system is ready to accept connections
LOG: autovacuum launcher process (PID 3788) was terminated by exception
0xC142
HINT: See C include file "ntstatus.
