Re: Removing "long int"-related limit on hash table sizes

Поиск
Список
Период
Сортировка
От Ranier Vilela
Тема Re: Removing "long int"-related limit on hash table sizes
Дата
Msg-id CAEudQAo4RT3bE6C9c=NDNoz0L+J7Qtf8q7aH57HcvP8iFg33ig@mail.gmail.com
обсуждение исходный текст
Ответ на Re: Removing "long int"-related limit on hash table sizes  (Tom Lane <tgl@sss.pgh.pa.us>)
Ответы Re: Removing "long int"-related limit on hash table sizes
Список pgsql-hackers
Em dom., 25 de jul. de 2021 às 15:53, Tom Lane <tgl@sss.pgh.pa.us> escreveu:
Ranier Vilela <ranier.vf@gmail.com> writes:
> I think int64 is in most cases the counterpart of *long* on Windows.

I'm not particularly on board with s/long/int64/g as a universal
solution. 
Sure, not a universal solution, I mean a start point.
When I look for a type that is signed and size 8 bytes in Windows, I only see int64.

I think that most of these usages are concerned with
memory sizes and would be better off as "size_t".
Ok, but let's not forget that size_t is unsigned.

  We might need
int64 in places where we're concerned with sums of memory usage
across processes, or where the value needs to be allowed to be
negative.  So it'll take case-by-case analysis to do it right.
Sure.


BTW, one aspect of this that I'm unsure how to tackle is the
common usage of "L" constants; in particular, "work_mem * 1024L"
is a really common idiom that we'll need to get rid of.  Not sure
that grep will be a useful aid for finding those.
I can see 30 matches in the head tree. (grep -d "1024L" *.c)

File backend\access\gin\ginfast.c:
        if (metadata->nPendingPages * GIN_PAGE_FREESIZE > cleanupSize * 1024L)
                         (accum.allocatedMemory >= workMemory * 1024L)))
Is it a good point to start?

or one more simple?
(src/backend/access/hash/hash.c) has one *long*.

regards,
Ranier Vilela

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

Предыдущее
От: Bryn Llewellyn
Дата:
Сообщение: Re: Have I found an interval arithmetic bug?
Следующее
От: Andrew Dunstan
Дата:
Сообщение: Re: Planning counters in pg_stat_statements (using pgss_store)