Re: [HACKERS] how to deal with sparse/to-be populated tables

Поиск
Список
Период
Сортировка
От Tom Lane
Тема Re: [HACKERS] how to deal with sparse/to-be populated tables
Дата
Msg-id 1706.949644413@sss.pgh.pa.us
обсуждение исходный текст
Ответ на Re: [HACKERS] how to deal with sparse/to-be populated tables  (Alfred Perlstein <bright@wintelcom.net>)
Список pgsql-hackers
Alfred Perlstein <bright@wintelcom.net> writes:
> (yes, I just thought about only indexing, and trying the update
> first and only on failure doing an insert, however we really can't
> determine if the initial update failed because no record matched(ok),
> or possible some other error (ouch))

Uh ... why not?  "UPDATE 0" is a perfectly recognizable result
signature, it seems like.  (I forget just how that looks at the
libpq API level, but if psql can see it so can you.)

Alternatively, if you think the insert is more likely to be the
right thing, try it first and look to see if you get a "can't
insert duplicate key into unique index" error.

You're right that SQL provides no combination statement that would
allow these sequences to be done with only one index probe.  But
FWIW, I'd think that the amount of wasted I/O would be pretty minimal;
the relevant index pages should still be in the buffer cache when
the second query gets to the backend.
        regards, tom lane


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

Предыдущее
От: Chris Bitmead
Дата:
Сообщение: Re: [HACKERS] Another nasty cache problem
Следующее
От: Tom Lane
Дата:
Сообщение: Re: [HACKERS] Another nasty cache problem