Re: [HACKERS] HOT and INSERT/DELETE

Pavan Deolasee wrote: > On 8/9/07, Bruce Momjian <[EMAIL PROTECTED]> wrote: > > > > 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 w

Re: [HACKERS] GUC for default heap fillfactor

On 8/8/07, Simon Riggs <[EMAIL PROTECTED]> wrote: > > > I see why you think that, but it is really just the first update that is > cold. All further updates on that block will be able to re-use the dead > row left by the first update. If they can't they will spread out to > other blocks where they

Re: [HACKERS] default_text_search_config and expression indexes

Oleg Bartunov wrote: > > Yea, seems more work than is necessary. If we require the configuration > > to be always supplied, and document that mismatches are a problem, I > > think we are in good shape. > > We should agree that all you describe is only for DUMMY users. > >From authors point of vi

Re: [HACKERS] HOT and INSERT/DELETE

On 8/9/07, Bruce Momjian <[EMAIL PROTECTED]> wrote: > > 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. As t

Re: [HACKERS] default_text_search_config and expression indexes

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 t

Re: [HACKERS] Function structure in formatting.c

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

Re: [HACKERS] Unexpected VACUUM FULL failure

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 XMIN_C

Re: [HACKERS] Function structure in formatting.c

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 wra

Re: [HACKERS] Unexpected VACUUM FULL failure

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 sup

Re: [HACKERS] Unexpected VACUUM FULL failure

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_MOV

Re: [HACKERS] default_text_search_config and expression indexes

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 wal

[HACKERS] HOT and INSERT/DELETE

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 r

Re: [HACKERS] GUC for default heap fillfactor

"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 o

[HACKERS] Unexpected VACUUM FULL failure

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

Re: [HACKERS] comunication protocol

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

Re: [HACKERS] comunication protocol

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) > du

Re: [HACKERS] GUC for default heap fillfactor

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 tupl

Re: [HACKERS] HOT patch, missing things

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 st

Re: [HACKERS] [EMAIL PROTECTED]: Re: [GENERAL] array_to_set functions]

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 colu

Re: [HACKERS] [EMAIL PROTECTED]: Re: [GENERAL] array_to_set functions]

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

Re: [HACKERS] GUC for default heap fillfactor

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 tu

Re: [HACKERS] [EMAIL PROTECTED]: Re: [GENERAL] array_to_set functions]

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 w

Re: [HACKERS] HOT patch, missing things

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 poi

Re: [HACKERS] pg_lzcompress strategy parameters

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

Re: [HACKERS] [EMAIL PROTECTED]: Re: [GENERAL] array_to_set functions]

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 aggrega

Re: [HACKERS] Function structure in formatting.c

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, advanta

Re: [HACKERS] RIP: Buildfarm member Baiji ??

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,

[HACKERS] comunication protocol

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 t

Re: [HACKERS] RIP: Buildfarm member Baiji ??

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

Re: [HACKERS] RIP: Buildfarm member Baiji ??

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

Re: [HACKERS] Function structure in formatting.c

"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. Ye

[HACKERS] Hello

Hello!!! this is a test!

Re: [HACKERS] [GENERAL] Template zero xid issue

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 connec

Re: [HACKERS] Postgresql service account issue!?

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 passwor

Re: [HACKERS] RIP: Buildfarm member Baiji ??

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 ungracefully.

[HACKERS] Postgresql service account issue!?

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 w

[HACKERS] RIP: Buildfarm member Baiji ??

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 fi

[HACKERS] GUC for default heap fillfactor

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 UPDAT

Re: [HACKERS] Wrote a connect-by feature

Hi, Am Mittwoch, 08. Aug 2007, 00:52:41 +0200 schrieb Bertram Scharpf: > I just extended it. Below an example. Bertram select * from simp; id | pid | nam +-+-- 1 | | Abe 2 |

[HACKERS] Function structure in formatting.c

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 a

Re: [HACKERS] HOT patch, missing things

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

Re: [HACKERS] HOT patch, missing things

"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 concl

Re: [HACKERS] HOT patch - version 13

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

Re: [HACKERS] HOT patch, missing things

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 >> import

Re: [HACKERS] HOT patch, missing things

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

Re: [HACKERS] HOT patch, missing things

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 w