On Mon, Dec 2, 2019 at 8:29 AM Aufar Gilbran wrote:
> Hello,
>
> I'm trying to figure out how to optimise 3-table (many-to-many relation)
> joins
> with predicate, limit, and ordering, where one of the tables returns at
> most one
> row.
>
> This is the query that I have right now:
>
> SELECT
I have managed to split the 365GB file into 2GB chunks with the help of
'split' unix utility in mingw shell like so
split -C 2GB ways.txt
Then I imported the files into a clean database with the help of the
following cmd command
for /f %f in ('dir /b') do psql -U postgres -w -d osm -t -c "set
All updated/dirty records go through PG internal memory buffer,
shared_buffers. Make sure that is configured optimally. Use
pg_buffercache extension to set it correctly.
Regards,
Michael Vitale
Hüseyin Demir wrote on 12/2/2019 12:13 PM:
I guess there won't be any adverse effect
Hi,
PostgreSQL decides which pages should be evicted from memory and written to
disk with the help of LRU algorithm. Thus, it depends on your query work
load. In OLTP systems, the algorithm is beneficial to business
requirements(almost :) )
It's hard to figure out that a configuration change
Hi,
I am looking for tuning my PG setup such that recently inserted or updated
record will be available in the buffer/cache (I believe they are same in
this context). Does PostgreSQL do it by default? If yes, just increasing
buffer size sufficient? What will be its effect on LRU performance -- I
Hello,
I'm trying to figure out how to optimise 3-table (many-to-many relation) joins
with predicate, limit, and ordering, where one of the tables returns at most one
row.
This is the query that I have right now:
SELECT entity.id
FROM (
SELECT entity_tag.entity_id
FROM tag
JOIN
On Sat, 2019-11-30 at 22:47 +0300, Eugene Podshivalov wrote:
> It sounds strange but the "type" is indeed impacting the overall
> performance somehow.
> I've just tried to execute the following sequence of commands on a
> fresh new database with PostreSQL v10 and both the copy and primary
> key