On 03/20/2017 03:08 PM, Dinesh Chandra 12108 wrote:
But on deletion it's not automatically re-adjusting the id's.
Do I need to create trigger for this??
It is possible to do but I advice against adjusting the IDs on DELETE
due to to do so safely would require locking the entire table in the
On 03/20/2017 02:43 PM, Josh Berkus wrote:
If I truncate the same table and then again insert rows should start
with 1 in “ID” column.
That's not how it works, normally. I'd suggest adding an ON TRUNCATE
trigger to the table.
Actually that may not be necessary as long as you make sure to
I have a couple of suggestions which should lead to some minor
improvements, but in general I am surprised by the huge size of the
result set. Is your goal really to get a 43 million row result? When a
query returns that many rows usually all possible query plans are more
or less bad.
1) You
there is a wal_sync_method but not a
checkpoint_sync_method.
The setting is for all uses of fsync within the PostgreSQL server, so if
you turn it off PostgreSQL should never issue fsync. The only exceptions
are some utility tools (eg. pg_basebackup) which do not read the
configuration file.
--
Andreas Karlsson
will realize that it can
replace g.id_gd with gd.id_gd in the where clause.
select g.gd_index, gd.full_name
from gd g join gd_data gd on (g.id_gd = gd.id_gd)
where gd.id_gd_data = OR gd.id_gd = ;
--
Andreas Karlsson
--
Sent via pgsql-performance mailing list (pgsql-performance
