Re: [PATCHES] GIN improvements

From: Teodor Sigaev <teodor(at)sigaev(dot)ru>
To: Heikki Linnakangas <heikki(dot)linnakangas(at)enterprisedb(dot)com>
Cc: Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us>, Pgsql Hackers <pgsql-hackers(at)postgresql(dot)org>
Subject: Re: [PATCHES] GIN improvements
Date: 2008-12-02 12:56:33
Message-ID: 49353081.9030304@sigaev.ru
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-hackers pgsql-patches

> grovel through. The situation will only be rectified at the next vacuum,
> but if there's no deletes or updates on the table, just inserts,
> autovacuum won't happen until the next anti-wraparound vacuum.
There is not agreement here, see
http://archives.postgresql.org/message-id/2818.1216753264@sss.pgh.pa.us

> Yet another problem is that if so much work is offloaded to autovacuum,
> it can tie up autovacuum workers for a very long time. And the work can
> happen on an unfortunate time, when the system is busy, and affect other
> queries. There's no vacuum_delay_point()s in gininsertcleanup, so
> there's no way to throttle that work.
Will insert.

> I think we need a hard limit on the number of list pages, before we can
> consider accepting this patch. After the limit is full, the next
> inserter can flush the list, inserting the tuples in the list into the
> tree, or just fall back to regular, slow, inserts.

Hard limit is not very good decision
- If it will make a flush when limit is reached then sometimes insert or update
will take unacceptable amount of time. Small limit is not very helpful, large
will takes a lot of time. Although if we calculate limit using work_mem setting
then, may be, it will be useful. Bulk insert will collect all pending pages in
memory at once.
- Falling back to regular insert will take long time for update of whole table -
and that was one of reasons of that patch. Users forget to drop GIN index before
a global update and query runs forever.

--
Teodor Sigaev E-mail: teodor(at)sigaev(dot)ru
WWW: http://www.sigaev.ru/

In response to

Responses

Browse pgsql-hackers by date

  From Date Subject
Next Message Simon Riggs 2008-12-02 13:09:46 Re: Sync Rep: First Thoughts on Code
Previous Message Hannes Eder 2008-12-02 12:44:36 WIP: The Skyline Operator

Browse pgsql-patches by date

  From Date Subject
Next Message Heikki Linnakangas 2008-12-02 14:11:01 Re: [PATCHES] GIN improvements
Previous Message Alvaro Herrera 2008-11-28 00:22:35 Re: [PATCHES] GIN improvements