Re: findoidjoins

Поиск
Список
Период
Сортировка
От Joe Conway
Тема Re: findoidjoins
Дата
Msg-id 3D763FA7.1020408@joeconway.com
обсуждение исходный текст
Ответ на Re: findoidjoins  (Alvaro Herrera <alvherre@atentus.com>)
Список pgsql-hackers
Tom Lane wrote:
> Joe Conway <mail@joeconway.com> writes:
>>Is it useful to have the reference count and unreferenced counts like 
>>currently written, or should I just faithfully reproduce the original 
>>behavior (except schema aware queries) using libpq in place of libpgeasy?>
> I'd be inclined to reproduce the original behavior.  findoidjoins is
> pretty slow already, and I don't much want to slow it down more in order
> to provide info that's useless for the primary purpose.

It was only taking about 7 seconds for me on an empty database, but if 
it's not useful I'll go back to the original output format.


>>It is probably easier to produce that output while looping 
>>through the first time versus running a script -- should I do that?
> 
> The separation between findoidjoins and make_oidjoins_check is
> deliberate --- this allows for easy hand-editing of the join list to
> remove unwanted joins before preparing the regression test script
> (cf the notes in the README about bogus joins).  Even though this is
> an extra manual step, I think it's a better answer than trying to make
> findoidjoins smart enough to suppress the bogus joins itself.  Part of
> the reason for running findoidjoins is to detect any unexpected
> linkages, so it should not be too eager to hide things.  Also, because
> the output of findoidjoins *should* be manually reviewed, it's better
> to put it out in an easy-to-read one-line-per-join format than to put
> out the finished regression script directly.

OK. I'll leave as is.

>>As written the queries did not know anything about schemas or the newer 
>>reg* data types, e.g. this:
>>Does the latter produce the desired result?
> 
> Not sure.  My oldest note saying it was busted predates the invention of
> the new reg* types, I think.  And while schema awareness is nice, it's
> not critical to the usefulness of the script: we're only really going to
> use it for checking the stuff in pg_catalog.  So I'm not at all sure why
> I made that note.  Do you get a plausible set of joins out of your
> version?

Looks plausible. But I guess it will be easier to tell once it produces 
results in the same format as before. I'll make the changes and send it 
in to patches.

Thanks,

Joe



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

Предыдущее
От: Joe Conway
Дата:
Сообщение: Re: HISTORY updated, 7.3 branded
Следующее
От: Bruce Momjian
Дата:
Сообщение: Re: HISTORY updated, 7.3 branded