Re: [HACKERS] Deferred trigger queue

Поиск
Список
Период
Сортировка
От wieck@debis.com (Jan Wieck)
Тема Re: [HACKERS] Deferred trigger queue
Дата
Msg-id m12IGZt-0003kMC@orion.SAPserv.Hamburg.dsh.de
обсуждение исходный текст
Ответ на Re: [HACKERS] Deferred trigger queue  (Tom Lane <tgl@sss.pgh.pa.us>)
Список pgsql-hackers
> wieck@debis.com (Jan Wieck) writes:
> >     looking at all the complications about dealing with segmented
> >     files etc., I wonder if it's really worth the efford  to  add
> >     file buffering to the trigger queue.
>
> You shouldn't be thinking about that.  Use a BufFile (see
> src/include/storage/buffile.h), and you have temp file creation,
> file segmentation and auto cleanup at xact abort with no more work
> than fopen/fwrite would be.  See nodeHash.c/nodeHashjoin.c for an
> example of use.
   You  already  pointed  me to that long ago. Surely, something   the like would be what to use in this case.

> However, if you think that there are other tasks that are higher
> priority than this one, I won't argue.
   It's not that I totally want to forget about  it.  It's  just   that  I  think  with 7 days left until BETA I better
starton   stressing the code and providing some docs instead of  taking   care for possible abuse.
 
   There  are  details that MUST be documented IMHO. For example   FOREIGN KEY needs that there is a UNIQUE  constraint
defined   on  the  set of referenced columns. Actually this requirement   is not checked in any way, so it MUST  be
mentioned in  the   docs.
 


Jan

--

#======================================================================#
# It's easier to get forgiveness for being wrong than for being right. #
# Let's break this rule - forgive me.                                  #
#========================================= wieck@debis.com (Jan Wieck) #




В списке pgsql-hackers по дате отправления:

Предыдущее
От: wieck@debis.com (Jan Wieck)
Дата:
Сообщение: Re: [HACKERS] docs and createlang patch for plperl
Следующее
От: Chris Bitmead
Дата:
Сообщение: Re: AW: [HACKERS] Another nasty cache problem