>
> Right, the problem occurs when you're deleting stuff that's at the end
> of the id range, and have already deleted stuff that was previously the
> end of the range. If you start somewhere in the middle and work towards
> the end, you dodge that problem, even for the very last delete that
> *is
Mohamed Wael Khobalatte writes:
> Tom, I think I understood what you meant after getting some sleep. What I
> do now is:
> - Initially load a lot of ids, say a million.
> - Then I slice that array by my preferred batch, say a 1.
> - Loop through these slices and run an improved query, which
On Fri, Jul 3, 2020 at 11:30 PM Mohamed Wael Khobalatte <
mkhobala...@grubhub.com> wrote:
> Another idea that might conceivably be useful to you on 9.6 is to
>
> reorganize the bulk deletions so that most of them aren't at the endpoint
>> of the live id range. If you made it so that the extremal
>
> Another idea that might conceivably be useful to you on 9.6 is to
reorganize the bulk deletions so that most of them aren't at the endpoint
> of the live id range. If you made it so that the extremal values are
> deleted last, you'd never hit this behavior.
>
> regard
Mohamed Wael Khobalatte writes:
> Do you happen to know if there is an upper limit to how much time the
> planner is willing to spend on this?
There is not. (I have considered that idea, but it's not implemented.
I'm not sure whether there's still much practical problem given the
v11+ behavior,
On Fri, Jul 3, 2020 at 10:16 PM Mohamed Wael Khobalatte <
mkhobala...@grubhub.com> wrote:
>
> On Fri, Jul 3, 2020 at 5:26 PM Tom Lane wrote:
>
>> Mohamed Wael Khobalatte writes:
>> > ... the migration itself runs as follows (each in a transaction, looping
>> > through records and sleeping for a
On Fri, Jul 3, 2020 at 5:26 PM Tom Lane wrote:
> Mohamed Wael Khobalatte writes:
> > ... the migration itself runs as follows (each in a transaction, looping
> > through records and sleeping for a bit)
>
> > WITH del AS (
> > DELETE FROM #{old_table}
> > WHERE id IN (
> > SELECT id
> >
On 7/3/20 3:24 PM, Mohamed Wael Khobalatte wrote:
Hi all,
I am attempting to do a bunch of table rewrites to shrink a table in the
absence of pg_repack and vacuum full (both not an option). The database is
growing fast and has had significant bloat in both heaps and indexes, so
index rebuilds
Mohamed Wael Khobalatte writes:
> ... the migration itself runs as follows (each in a transaction, looping
> through records and sleeping for a bit)
> WITH del AS (
> DELETE FROM #{old_table}
> WHERE id IN (
> SELECT id
> FROM #{old_table}
> WHERE id > #{max_deleted_id} -- This is
On Fri, Jul 3, 2020 at 4:24 PM Mohamed Wael Khobalatte <
mkhobala...@grubhub.com> wrote:
> Hi all,
>
> I am attempting to do a bunch of table rewrites to shrink a table in the
> absence of pg_repack and vacuum full (both not an option). The database is
> growing fast and has had significant bloat
10 matches
Mail list logo
