On 9/19/07, Decibel! [EMAIL PROTECTED] wrote:
Odd... I'd expect it to actually be beneficial to run analyze on a table
at roughly the same time as PK building, because you'd make better use
of cache.
Sure if your database fits entirely in RAM (otherwise if two big
tables are analyzed while we
On Tue, 2007-08-07 at 17:03 -0400, Tom Lane wrote:
Simon Riggs [EMAIL PROTECTED] writes:
How hard will it be to add the infrastructure to allow new index types
to be added to the server dynamically?
INSERT INTO pg_am VALUES (...);
I don't really think we need more than that, at least
On Tue, 2007-09-18 at 12:10 -0400, Tom Lane wrote:
I wrote:
* The patch makes undocumented changes that cause autovacuum's decisions
to be driven by total estimated dead space rather than total number of
dead tuples. Do we like this?
No one seems to have picked up on this point, but
Decibel! wrote:
On Tue, Sep 18, 2007 at 11:32:52AM -0400, Tom Lane wrote:
Another option would be to prune whenever the free space goes
below table fillfactor and hope that users would set fillfactor so that
atleast one updated tuple can fit in the block. I know its not best to
rely on the
Tom Lane wrote:
Heikki Linnakangas [EMAIL PROTECTED] writes:
We could lift the limitation that you can't defragment a page that's
pinned, if we play some smoke and mirrors in the buffer manager. When
you prune a page, make a *copy* of the page you're pruning, and keep
both versions in the
On 19/09/2007, Tom Lane [EMAIL PROTECTED] wrote:
Radoslaw Zielinski [EMAIL PROTECTED] writes:
pg_ctl -w -D ... start doesn't work when unix_socket_directory is set
to somewhere else than the compiled in default (/tmp).
pg_ctl not working is going to be the very least of your worries;
pretty
Heikki Linnakangas [EMAIL PROTECTED] writes:
There is one wacky idea I haven't dared to propose yet:
We could lift the limitation that you can't defragment a page that's
pinned, if we play some smoke and mirrors in the buffer manager. When
you prune a page, make a *copy* of the page you're
Decibel! [EMAIL PROTECTED] writes:
3 isn't that important to me, but 4 is:
4. Doesn't hammer the database to measure
And pgstattuple fails #4 miserably. Want to know the average dead space
in a 500GB database? Yeah, right
So we could put a vacuum_cost_delay() in it ...
Simon Riggs [EMAIL PROTECTED] writes:
We're able to dynamically add AMs in the way you suggest, but there is
no way to alter the RMgrTable to either add a new RM or re-assign one of
the unused RMs.
Hmmm...
1. Remove the Const in front of RmgrTable in rmgr.c. That would allow
re-assignment
Stefan Kaltenbrunner [EMAIL PROTECTED] writes:
Tom Lane wrote:
Stefan Kaltenbrunner [EMAIL PROTECTED] writes:
! ERROR: could not read block 2 of relation 1663/16384/2606: read only 0
of 8192 bytes
Is that repeatable? What sort of filesystem are you testing on?
(soft-mounted NFS by any
Andrew, All,
On 5/22/07, Andrew Dunstan [EMAIL PROTECTED] wrote:
But before I commit this I'd appreciate seeing some more testing, both
for correctness and performance.
I finally found some time to test this patch on our data. As our
production database is still using 8.1, I made my tests
Tom Lane wrote:
Stefan Kaltenbrunner [EMAIL PROTECTED] writes:
Tom Lane wrote:
Stefan Kaltenbrunner [EMAIL PROTECTED] writes:
! ERROR: could not read block 2 of relation 1663/16384/2606: read only 0 of
8192 bytes
Is that repeatable? What sort of filesystem are you testing on?
On Sep 19, 2007, at 8:08 AM, Tom Lane wrote:
Decibel! [EMAIL PROTECTED] writes:
3 isn't that important to me, but 4 is:
4. Doesn't hammer the database to measure
And pgstattuple fails #4 miserably. Want to know the average dead
space
in a 500GB database? Yeah, right
So we could put a
On Sep 19, 2007, at 2:08 AM, Guillaume Smet wrote:
On 9/19/07, Decibel! [EMAIL PROTECTED] wrote:
Odd... I'd expect it to actually be beneficial to run analyze on a
table
at roughly the same time as PK building, because you'd make better
use
of cache.
Sure if your database fits entirely in
Andrew Dunstan wrote:
Tom Lane wrote:
Stefan Kaltenbrunner [EMAIL PROTECTED] writes:
Tom Lane wrote:
Stefan Kaltenbrunner [EMAIL PROTECTED] writes:
! ERROR: could not read block 2 of relation 1663/16384/2606: read
only 0 of 8192 bytes
Is that repeatable? What
Tom Lane wrote:
Stefan Kaltenbrunner [EMAIL PROTECTED] writes:
Tom Lane wrote:
Stefan Kaltenbrunner [EMAIL PROTECTED] writes:
! ERROR: could not read block 2 of relation 1663/16384/2606: read only 0 of
8192 bytes
Is that repeatable? What sort of filesystem are
Zdenek Kotala [EMAIL PROTECTED] writes:
Just for information. Venezuela is going to have new timezone change
(30minutes
shift) on this weekend. This change is not yet integrated in the last version
in Olson database. (Original announcement said it happens on 1.1.2008)
Is there still time
Andrew Dunstan [EMAIL PROTECTED] writes:
pgbfprod=# select sysname, stage, snapshot from build_status where log ~
$$read only \d+ of \d+ bytes$$;
sysname |stage | snapshot
---+--+-
zebra | InstallCheck | 2007-09-11
Stefan Kaltenbrunner [EMAIL PROTECTED] writes:
Andrew Dunstan wrote:
pgbfprod=# select sysname, stage, snapshot from build_status where log ~
$$read only \d+ of \d+ bytes$$;
sysname |stage | snapshot
---+--+-
zebra |
Gregory Stark wrote:
Stefan Kaltenbrunner [EMAIL PROTECTED] writes:
Andrew Dunstan wrote:
pgbfprod=# select sysname, stage, snapshot from build_status where log ~
$$read only \d+ of \d+ bytes$$;
sysname |stage | snapshot
Gregory Stark wrote:
Is there still time to slip this into the upcoming 8.2.5?
8.2.5 is no longer upcoming.
--
Peter Eisentraut
http://developer.postgresql.org/~petere/
---(end of broadcast)---
TIP 4: Have you searched our list archives?
Guillaume Smet wrote:
Andrew, All,
On 5/22/07, Andrew Dunstan [EMAIL PROTECTED] wrote:
But before I commit this I'd appreciate seeing some more testing, both
for correctness and performance.
I finally found some time to test this patch on our data. As our
production
Hello,
I am with a problem. When I am using debugger, breakpoints that they are
inside of main function (stop the execution in the marked point) but when
breakpoint is marked in another archive (index.c for example) breakpoint
does not function (the execution in the point does not stop), because
On Tue, 2007-09-18 at 19:13 -0400, Tom Lane wrote:
Radoslaw Zielinski [EMAIL PROTECTED] writes:
pg_ctl -w -D ... start doesn't work when unix_socket_directory is set
to somewhere else than the compiled in default (/tmp).
pg_ctl not working is going to be the very least of your worries;
Looking back, by far the largest change in the period Sep 1 - Sep 11 was the
lazy xid calculation and read-only transactions. That seems like the most
likely culprit.
But given Tom's comments this commit stands out too:
---BeginMessage---
Log Message:
---
Release the exclusive lock on
Pedro Belmino wrote:
I am with a problem. When I am using debugger, breakpoints that they
are inside of main function (stop the execution in the marked point)
but when breakpoint is marked in another archive (index.c for
example) breakpoint does not function (the execution in the point
does
On 9/19/07, Andrew Dunstan [EMAIL PROTECTED] wrote:
It's at least good to see that the LIKE case has some useful speedup in
8.3.
It can be due to your patch or to the varlena header patch. Seqscan is
a bit faster too.
Can you run the same set of tests in a single byte encoding like latin1?
Gregory Stark [EMAIL PROTECTED] writes:
But given Tom's comments this commit stands out too:
From: Alvaro Herrera [EMAIL PROTECTED]
Log Message:
---
Release the exclusive lock on the table early after truncating it in lazy
vacuum, instead of waiting till commit.
I had thought about
On 9/19/07, Andrew Dunstan [EMAIL PROTECTED] wrote:
Can you run the same set of tests in a single byte encoding like latin1?
Here are the results (each query was executed several times before this result):
** 8.1 **
cityvox_latin1=# SELECT e.numeve FROM evenement e WHERE e.libgeseve
ILIKE
Guillaume Smet wrote:
On 9/19/07, Andrew Dunstan [EMAIL PROTECTED] wrote:
Can you run the same set of tests in a single byte encoding like latin1?
Here are the results (each query was executed several times before this result):
** 8.1 **
cityvox_latin1=# SELECT e.numeve FROM
30 matches
Mail list logo
