Heavy archive log generation in PostgreSQL - postgresql-9.1

Question

We are using PostgreSQL 9.1 in our production server. From the past one month, our database is generating nearly 35 GB of archive logs on a daily basis. For that, we have monitored what are all the queries are being run at the time of archive log generation. Then we ran vacuum(freeze,analyze) on the whole database. But it seems to be no effect on the archive log generation. We have suspected one table for this. Every 9th and 39th minute of an hour, same delete statement is being running. It is deleting the whole table each time it gets executed. For test purpose, we ran EXPLAIN(ANALYZE,BUFFERS) against the statement. We found that read = 576 MB and written = 328 MB. But, in our production server, shared_buffers = 24 MB.
So, each and every time it is taking 24 MB of data blocks from the disk to shared buffer. Then it will flush to disk and again it will take 24 MB of data blocks into the shared buffers.
So, is the reason of archive log generation is because of frequent flushing of data blocks ? Shall we need to increase shared_buffers in our production server to get rid of heavy archive log generation?
In our production server, work_mem = 1 MB
Here is the output of EXPLAIN(ANALYZE,BUFFERS) for your information:
QUERY PLAN
---------------------------------------------------------------------------------------------------------------------------------------------
Delete on table_a (cost=83.35..171.85 rows=2060 width=12) (actual time=11949.929..11949.929 rows=0 loops=1)
Buffers: shared hit=375963 read=73999 written=42030
-> Hash Semi Join (cost=83.35..171.85 rows=2060 width=12) (actual time=1.028..12.570 rows=2060 loops=1)
Hash Cond: (public.table_a.id = public.table_a.id)
Buffers: shared hit=46 read=30 written=18
-> Seq Scan on table_a (cost=0.00..57.60 rows=2060 width=10) (actual time=0.007..5.009 rows=2060 loops=1)
Buffers: shared hit=7 read=30 written=18
-> Hash (cost=57.60..57.60 rows=2060 width=10) (actual time=0.973..0.973 rows=2060 loops=1)
Buckets: 1024 Batches: 1 Memory Usage: 89kB
Buffers: shared hit=37
-> Seq Scan on table_a (cost=0.00..57.60 rows=2060 width=10) (actual time=0.002..0.463 rows=2060 loops=1)
Buffers: shared hit=37
Total runtime: 11950.028 ms

Answer 1

https://www.postgresql.org/docs/9.1/static/wal-intro.html
Briefly, WAL's central concept is that changes to data files (where
tables and indexes reside) must be written only after those changes
have been logged, that is, after log records describing the changes
have been flushed to permanent storage. If we follow this procedure,
we do not need to flush data pages to disk on every transaction
commit, because we know that in the event of a crash we will be able
to recover the database using the log: any changes that have not been
applied to the data pages can be redone from the log records. (This is
roll-forward recovery, also known as REDO.)
So in short INSERT, UPDATE, DELETE, VACUUM, CLUSTER, ALTER.. SET TABLESPACE (and other similar) produce WALs. As more blocks are rewritten as more WALs created. shared_buffers will not affect it.