Re: Why could different data in a table be processed with different performance?

Поиск
Список
Период
Сортировка
От Vladimir Ryabtsev
Тема Re: Why could different data in a table be processed with different performance?
Дата
Msg-id CAMqTPqkYs+sfikTkzDuBd8yXX7+pMThW1ErfBYzw-yLRT=9Y7Q@mail.gmail.com
обсуждение исходный текст
Ответ на Re: Why could different data in a table be processed with differentperformance?  (Fabio Pardi <f.pardi@portavita.eu>)
Ответы Re: Why could different data in a table be processed with differentperformance?
Список pgsql-performance
> You will have lesser
> slots in the cache, but the total available cache will indeed be
> unchanged (half the blocks of double the size).
But we have many other tables, queries to which may suffer from smaller number of blocks in buffer cache.

> To change block size is a
> painful thing, because IIRC you do that at db initialization time
My research shows that I can only change it in compile time.
And then initdb a new cluster...
Moreover, this table/schema is not the only in the database, there is a bunch of other schemas. And we will need to dump-restore everything... So this is super-painful.

> It could affect space storage, for the smaller blocks.
But at which extent? As I understand it is not something about "alignment" to block size for rows? Is it only low-level IO thing with datafiles?

> But before going through all this, I would first try to reload the data
> with dump+restore into a new machine, and see how it behaves.
Yes, this is the plan, I'll be back once I find enough disk space for my further experiments.

Vlad

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

Предыдущее
От: Vladimir Ryabtsev
Дата:
Сообщение: Re: Why could different data in a table be processed with different performance?
Следующее
От: David Rowley
Дата:
Сообщение: Re: To keep indexes in memory, is large enough effective_cache_size enough?