Bruce Momjian [EMAIL PROTECTED] writes:
Tom Lane wrote:
So instead of pressing to try to get something into 8.3, I would rather
we stand back and think about it some more.
I understand why you are saying hold for 8.4, but this issue came up in
the middle of the 8.3 development cycle and
Tom Lane wrote:
Bruce Momjian [EMAIL PROTECTED] writes:
Tom Lane wrote:
So instead of pressing to try to get something into 8.3, I would rather
we stand back and think about it some more.
I understand why you are saying hold for 8.4, but this issue came up in
the middle of the 8.3
Mark Mielke wrote:
Stefan Kaltenbrunner wrote:
Heikki Linnakangas wrote:
2. Pointer swinging. At the moment, after a row is HOT updated, the only
way to get rid of the redirecting line pointer is to run VACUUM FULL or
CLUSTER (or delete or cold update the row and vacuum). If we want to
On 8/7/07, Heikki Linnakangas [EMAIL PROTECTED] wrote:
There's three things clearly missing in the patch:
Yes, these are the major ones, though we might want to play with
the chain pruning, FSM handling and other smaller things to see
if there are any performance benefits.
1. HOT updates on
Simon Riggs wrote:
On Tue, 2007-08-07 at 19:01 +0100, Heikki Linnakangas wrote:
There's three things clearly missing in the patch:
1. HOT updates on tables with expression or partial indexes. Hasn't been
done yet because it should be pretty straightforward and we've had more
important things
On 8/7/07, Simon Riggs [EMAIL PROTECTED] wrote:
On Tue, 2007-08-07 at 18:25 +0530, Pavan Deolasee wrote:
I am posting the version 13 of HOT patch on pgsql-patches. It
includes the changes based on feedback received on version 11.
I think we need a change log, so we can see which feedback
Heikki Linnakangas [EMAIL PROTECTED] writes:
Because we can truncate dead tuples, even from cold updates and deletes,
to redirected dead line pointers which take much less space than dead
tuples, maybe we should increase the default autovacuum threshold?
That would be the logical conclusion
On 8/8/07, Gregory Stark [EMAIL PROTECTED] wrote:
It seems that previously percentage of tuples made sense because dead
tuples
took about the same amount of space as new tuples that need that space.
But
line pointers take much less space than the new tuples so the number of
dead
line
Hi hackers,
I'm currently poking around in backend/utils/adt/formatting.c with a
view to improving to_date() parsing (see thread at
http://archives.postgresql.org/pgsql-hackers/2007-07/msg00513.php),
and I've noticed that the way the functions are organised is pretty
weird.
The original author
Hi,
Am Mittwoch, 08. Aug 2007, 00:52:41 +0200 schrieb Bertram Scharpf:
http://www.bertram-scharpf.de/tmp/connectby.tar.gz
I just extended it. Below an example.
Bertram
select * from simp;
id | pid | nam
+-+--
1 | | Abe
2 |
If HOT gets into 8.3, we might need a GUC to set database wide heap
fillfactor to an appropriate value. The only way to so today is compile
time value of DEFAULT_HEAP_FILLFACTOR. HOT works much
better if there is atleast one tuple worth of free space in each block.
Otherwise atleast the first
Completely off-topic I know, but I felt I had to mention this one...
The buildfarm machine known as Baiji runs on a PC sat next to my desk.
About 30 minutes ago, a breaker tripped, leaving the office without it's
ring main, consequently shutting down Baiji rather ungracefully.
We get the power
Hi,
I have an issue regarding the PostgreSQL service account on my machine. I
work for IBM and I have to fulfil security checks for my machine to make
sure its safe. Anyway, it is flagging up the problem that my account for
postgres doesnt have a screensaver set with a password?? Any ideas on
Dave Page wrote:
Completely off-topic I know, but I felt I had to mention this one...
The buildfarm machine known as Baiji runs on a PC sat next to my desk.
About 30 minutes ago, a breaker tripped, leaving the office without it's
ring main, consequently shutting down Baiji rather
Thomas Foster wrote:
I have an issue regarding the PostgreSQL service account on my
machine. I work for IBM and I have to fulfil security checks for my
machine to make sure its safe. Anyway, it is flagging up the problem
that my account for postgres doesnt have a screensaver set with a
Decibel! [EMAIL PROTECTED] writes:
On Tue, Aug 07, 2007 at 06:46:05PM -0400, Tom Lane wrote:
I'm tempted to stop accepting connections once we start the shutdown
checkpoint (ie, tell the bgwriter to shut down). This would at least
limit the width of the window in which incoming connections
Hello!!!
this is a test!
Brendan Jurd [EMAIL PROTECTED] writes:
To my mind, it would make a lot more sense (and make hacking the file
a lot easier) if the processing functions were split into to_char and
from_char variants. I'm not sure what, if any, advantage is gleaned
by having these functions combined.
Yeah, I
Dave Page [EMAIL PROTECTED] writes:
http://www.theregister.co.uk/2007/08/08/yangtze_dolphin_extinct/
Coincidence? Or a sign from $DEITY?
Speaking of baiji ... why has it been failing, with nothing at all in
the log, for the last month?
regards, tom lane
Tom Lane wrote:
Dave Page [EMAIL PROTECTED] writes:
http://www.theregister.co.uk/2007/08/08/yangtze_dolphin_extinct/
Coincidence? Or a sign from $DEITY?
Speaking of baiji ... why has it been failing, with nothing at all in
the log, for the last month?
Hmm, did realise it had been - sorry.
Hi,
I have installed postgresql to my client as a server for a progam
(libpq.dll/VCL based) that I wrote for them.
Every is working fine, but I noted some general slowness, compared with an
older database system (iAnywhere ADS)
due (I think) to the text based communication protocol.
I know
Dave Page wrote:
Tom Lane wrote:
Dave Page [EMAIL PROTECTED] writes:
http://www.theregister.co.uk/2007/08/08/yangtze_dolphin_extinct/
Coincidence? Or a sign from $DEITY?
Speaking of baiji ... why has it been failing, with nothing at all in
the log, for the last month?
Hmm, did realise it
On 8/9/07, Tom Lane [EMAIL PROTECTED] wrote:
Brendan Jurd [EMAIL PROTECTED] writes:
To my mind, it would make a lot more sense (and make hacking the file
a lot easier) if the processing functions were split into to_char and
from_char variants. I'm not sure what, if any, advantage is
On Tue, Aug 07, 2007 at 10:18:32PM -0700, Jeremy Drake wrote:
On Tue, 7 Aug 2007, Decibel! wrote:
ISTM that having a built-in array_to_set function would be awfully
useful... Is the aggregate method below an acceptable way to do it?
Umm, the array_to_set function is not an aggregate.
On 8/5/2007 6:30 PM, Tom Lane wrote:
Gregory Stark [EMAIL PROTECTED] writes:
(Incidentally, this means what I said earlier about uselessly trying to
compress objects below 256 is even grosser than I realized. If you have a
single large object which even after compressing will be over the toast
On Wed, Aug 08, 2007 at 04:45:44PM +0530, Pavan Deolasee wrote:
On 8/8/07, Gregory Stark [EMAIL PROTECTED] wrote:
It seems that previously percentage of tuples made sense because dead
tuples
took about the same amount of space as new tuples that need that space.
But
line pointers take
On Aug 8, 2007, at 11:41 , Decibel! wrote:
On Tue, Aug 07, 2007 at 10:18:32PM -0700, Jeremy Drake wrote:
select * from information_schema._pg_expandarray(ARRAY['foo',
'bar', 'baz']);
x | n
-+---
foo | 1
bar | 2
baz | 3
(3 rows)
Not exactly well documented or well known, but it
On Wed, Aug 08, 2007 at 06:05:06PM +0530, Pavan Deolasee wrote:
If HOT gets into 8.3, we might need a GUC to set database wide heap
fillfactor to an appropriate value. The only way to so today is compile
time value of DEFAULT_HEAP_FILLFACTOR. HOT works much
better if there is atleast one tuple
On Wed, Aug 08, 2007 at 12:03:34PM -0500, Michael Glaesemann wrote:
Personally, I think expandarray is more appropriate and its
functionality probably more generally useful, as it identifies the
array indices as well. Note you can also rename the columns.
Sure. My point is that we should
On Aug 8, 2007, at 12:18 , Decibel! wrote:
On Wed, Aug 08, 2007 at 12:03:34PM -0500, Michael Glaesemann wrote:
Personally, I think expandarray is more appropriate and its
functionality probably more generally useful, as it identifies the
array indices as well. Note you can also rename the
On Wed, 2007-08-08 at 09:55 +0100, Heikki Linnakangas wrote:
3. Statistics and autovacuum integration. How should HOT updates be
taken into account when deciding when to autovacuum and autoanalyze?
There's a FIXME comment in analyze.c related to this as well. What
additional statio
On Wed, 2007-08-08 at 18:05 +0530, Pavan Deolasee wrote:
If HOT gets into 8.3, we might need a GUC to set database wide heap
fillfactor to an appropriate value. The only way to so today is
compile
time value of DEFAULT_HEAP_FILLFACTOR. HOT works much
better if there is atleast one tuple
On 8/8/07, Omar Bettin [EMAIL PROTECTED] wrote:
Hi,
I have installed postgresql to my client as a server for a progam
(libpq.dll/VCL based) that I wrote for them.
Every is working fine, but I noted some general slowness, compared with an
older database system (iAnywhere ADS)
due (I
Em Quarta 08 Agosto 2007 12:02, Omar Bettin escreveu:
Hi,
I have installed postgresql to my client as a server for a progam
(libpq.dll/VCL based) that I wrote for them.
Borland VCL? What component are you using?
Gustavo.
pgp81qX9X4CeQ.pgp
Description: PGP signature
This is a bit disturbing:
*** ./expected/vacuum.out Sat Jul 20 00:58:14 2002
--- ./results/vacuum.outWed Aug 8 20:16:45 2007
***
*** 50,55
--- 50,56
DELETE FROM vactst WHERE i != 0;
VACUUM FULL vactst;
+ ERROR: HEAP_MOVED_OFF was expected
DELETE FROM
Pavan Deolasee [EMAIL PROTECTED] wrote:
If HOT gets into 8.3, we might need a GUC to set database wide heap
fillfactor to an appropriate value.
I have no objection to do that, but we will need other default values soon,
something like default_[heap|btree|hash|gist|gin]_fillfactor. Some of us
I was wondering about HOT behavior.
Will an INSERT reuse rows no longer visible caused by an UPDATE or
DELETE, or if an UPDATE will reuse rows expired by an invisible DELETE?
It seems both of these would be possible and useful.
My basic question is HOT UPDATE-only in both operation and expired
Heikki Linnakangas wrote:
Sure, but you have make sure you use the right configuration in the
trigger, no? Does the tsquery have to use the same configuration?
I wish I knew this myself. :-) Whatever I had done happened to work
but that was largely through people on IRC walking me
Tom Lane wrote:
This is a bit disturbing:
*** ./expected/vacuum.out Sat Jul 20 00:58:14 2002
--- ./results/vacuum.out Wed Aug 8 20:16:45 2007
***
*** 50,55
--- 50,56
DELETE FROM vactst WHERE i != 0;
VACUUM FULL vactst;
+ ERROR: HEAP_MOVED_OFF was
Alvaro Herrera [EMAIL PROTECTED] writes:
Tom Lane wrote:
I couldn't reproduce it in a few tries. A reasonable guess is that
it's triggered by autovacuum deciding to vacuum the table sometime
before the VACUUM FULL starts. Anyone want to try to reproduce it?
Hum, aren't vacuums supposed to
Just quick update on this. It turns out (as it always does) that I
want to refactor a bit more intensively than I first suggested.
The functions dch_global, dch_time and dch_date seem to be wholly
pointless, since dch_global is effectively a one-liner for the FX
flag, and the other two merely
I wrote:
... Since we've whacked the tqual.c logic around recently,
the problem might actually lie there...
In fact, I bet this is a result of the async-commit patch. The places
where vacuum.c bleats HEAP_MOVED_OFF was expected are all places where
it is looking at a tuple not marked
On 8/9/07, Brendan Jurd [EMAIL PROTECTED] wrote:
Just quick update on this. It turns out (as it always does) that I
want to refactor a bit more intensively than I first suggested.
[...]
This means there is no need to put pointers to action functions in
each of the KeyWords. It makes the
On Wed, 8 Aug 2007, Bruce Momjian wrote:
Heikki Linnakangas wrote:
Sure, but you have make sure you use the right configuration in the
trigger, no? Does the tsquery have to use the same configuration?
I wish I knew this myself. :-) Whatever I had done happened to work
but that was largely
44 matches
Mail list logo
