Hi!
With following kinds of keywords, it is possible to find / search for cloud
native (SQL) implementations e.g. with google:
cloud native sql database
E.g. CockroachDB, YugaByteDB.
I do not know are you planning to do it by other means (by yourself).
I myself would be interested, has someone ha
o 4 partitions, in a partitioned table. CPU load increased, but not
full yet.Same results with open_datasync.
BR Sam
On pe, lokak. 12, 2018 at 19:27, Sam R. wrote: Hi!
Could someone discuss about following? It would be great to hear comments!
There is a good storage. According to "f
Hi!
Could someone discuss about following? It would be great to hear comments!
There is a good storage. According to "fio", write speed could be e.g. 3 GB/s.
(It is First time using the command for me, so I am not certain of the real
speed with "fio". E.g. with --bs=100m, direct=1, in fio. The m
red
buffers etc.).
Please correct me if I am wrong.
BR Sam
On ti, syysk. 25, 2018 at 23:55, David Rowley
wrote: On Tue, 25 Sep 2018 at 18:36, Sam R. wrote:
> Regarding double buffering: I do not know how much double buffering would
> slow down operations.
> It could also be po
maybe PostgreSQL works well in our case.
Regarding double buffering: I do not know how much double buffering would slow
down operations.
It could also be possible to turn off kernel page cache on our DB server, to
avoid double buffering. Although, we may still keep it in use.
BR Sam
On Wedn
Thanks for the comments!
Sam wrote:
>> The data in db table columns is not needed to be kept in memory, only the
>> index. (hash index.)
Jeff Janes wrote:
> This sounds like speculation. Do you have hard evidence that this is
> actually the case?
In our case the "ID" is randomly generated ran
Size of the index of one huge table has been e.g. 16-20 GB (after REINDEX).
Size of such an index is quite big.
BR Samuli
On Wednesday, September 19, 2018 2:01 PM, Sam R.
wrote:
Hi!
Thanks for all of the comments!
David wrote:> if you mention
> how muchRAM the server has a
bit bigger value than 64 GB, if needed to. )
BR Sam
On Wednesday, September 19, 2018 1:11 PM, David Rowley
wrote:
On 19 September 2018 at 21:18, Sam R. wrote:
> Ok. So, we should set also shared_buffers big.
It might not be quite as beneficial as you might think. If your
database
Sergei wrote:
> You can not pin any table or index to shared buffers.
Thanks, this is answer to my other question!
In our case, this might be an important feature.
(Index in memory, other data / columns not.)
> shared_buffers is cache for both tables and indexes pages.
Ok. So, we should set also s
very big index in memory?
I ma also reading a PG book.
Best Regards, Sam
On Wednesday, September 19, 2018 11:40 AM, Sam R.
wrote:
Hi!
Related to my other email (size of index in memory),
Other questions,
Q: To keep _index(es)_ in memory, is large enough effective_cache_size enough
Hi!
Related to my other email (size of index in memory),
Other questions,
Q: To keep _index(es)_ in memory, is large enough effective_cache_size enough?
Q: Size of shared_buffers does not matter regarding keeping index in memory?
Or have I missed something, does it matter (to keep indexes in mem
Hi!
I would have following question, if someone could help.
Question 1: How to see/calculate size of index in memory?
BTree, hash index.
I can see size of index e.g. with pg_relation_size FROM pg_class (after
reindex). Does that tell size of index on disk?
I would be interested how big part o
12 matches
Mail list logo
