PostgreSQL Vacuum---索引删除

已于 2022-06-22 11:31:09 修改
阅读量4.3k 收藏 5
点赞数 5
分类专栏： postgresql 文章标签： postgresql 数据库 database
于 2021-11-15 10:09:52 首次发布
版权声明：本文为博主原创文章，遵循 CC 4.0 BY-SA 版权协议，转载请附上原文出处链接和本声明。
本文链接：https://blog.csdn.net/obvious__/article/details/121329012
版权

PostgreSQL Vacuum—索引删除

预备知识

《PostgreSQL Vacuum—元组删除》

《PostgreSQL B+树索引—并发控制》

概述

在《PostgreSQL Vacuum—元组删除》中，我们现实阐述了元组的删除过程，从中我们知道，在删除索引之前HOT链的链头元组的ItemData只能被标记为LP_DEAD来防止重用，只有当索引删除之后ItemData才能标记为LP_UNUSED以供重用。所以本章我们将来阐述如何删除索引。索引的删除有如下两个场景：

  • 用户执行Vaccum命令

  • 索引执行插入操作

    向索引插入index tuple时，如果发现待插入的页面没有足够的空闲空间，会先尝试对页面进行空间整理。

本文将重点阐述这两个场景的实现细节。

Lazy Vacuum

在《PostgreSQL Vacuum—元组删除》中我们阐述了Lazy Vaccum如何删除元组，现在我们可以来看看Lazy Vacuum如何删除索引。Vacuum操作要做的事情很多，包括删除元组、冻结事务标识、更新空间映射表、更新可见性映射表等，这里我们只关注删除元组操作。Lazy Vacuum的核心函数是lazy_scan_heap，这个函数非常长，就不看代码了，只讨论与删除相关的流程，在流程的每个步骤中给出代码位置：

  • 步骤1：遍历表的所有数据块（vacuumlazy.c line:585）

  • 步骤2：对每一个块调用heap_page_prune清理过期元组（vacuumlazy.c line:911）

    通过《PostgreSQL Vacuum—元组删除》我们知道，heap_page_prune完成后，块中会留下标记为LP_DEAD的元组，我们将它们称为dead tuple。

  • 步骤3：创建dead tuple数组记录表中所有元组dead tuple的tid（vacuumlazy.c line:961）

  • 步骤4：删除dead tuple数组对应的索引元组（lazy_vacuum_index()函数，vacuumlazy.c line:1304）

  • 步骤5：将dead tuple数组中所有元组的标识改为LP_UNUSED（lazy_vacuum_heap()函数，vacuumlazy.c line:1317）

在这5个步骤中，我们需要重点关注步骤4，通过调用lazy_vacuum_index来删除索引，下面我们来看看lazy_vacuum_index的实现。

lazy_vacuum_index

lazy_vacuum_index最终会调用到btvacuumscan函数，btvacuumscan的核心代码如下：

blkno = BTREE_METAPAGE + 1;
for (;;)
{
    /* Get the current relation length */
    if (needLock)
        LockRelationForExtension(rel, ExclusiveLock);
    	num_pages = RelationGetNumberOfBlocks(rel);
    if (needLock)
        UnlockRelationForExtension(rel, ExclusiveLock);

    /* Quit if we've scanned the whole relation */
    if (blkno >= num_pages)
        break;
    /* Iterate over pages, then loop back to recheck length */
    for (; blkno < num_pages; blkno++)
    {
        btvacuumpage(&vstate, blkno, blkno);
    }
}

btvacuumpage

上述代码遍历索引的所有块，对于每个块调用btvacuumpage对块的索引元组进行删除，该函数主要有三个步骤：

  • 步骤1：遍历页面内索引元组，判断元组是否可以删除。

    判断元组删除是通过调用callback函数来实现，callback是一个函数指针，实际指向lazy_tid_reaped函数，而lazy_tid_reaped会校验index tuple的tid是否存在于dead tuple数组中（此外dead tuple数组是按照tid升序排列，所以在校验的时候会采用二分法）。

  • 步骤2：使用deletable数组记录需要删除的元组。

  • 步骤3：调用_bt_delitems_vacuum删除deletable中的元组。

btvacuumpage的实现如下：

static void
btvacuumpage(BTVacState *vstate, BlockNumber blkno, BlockNumber orig_blkno)
{
	IndexVacuumInfo *info = vstate->info;
	IndexBulkDeleteResult *stats = vstate->stats;
	IndexBulkDeleteCallback callback = vstate->callback;
	void	   *callback_state = vstate->callback_state;
	Relation	rel = info->index;
	bool		delete_now;
	BlockNumber recurse_to;
	Buffer		buf;
	Page		page;
	BTPageOpaque opaque = NULL;

restart:
	delete_now = false;
	recurse_to = P_NONE;

	/* call vacuum_delay_point while not holding any buffer lock */
	vacuum_delay_point();

	/*
	 * We can't use _bt_getbuf() here because it always applies
	 * _bt_checkpage(), which will barf on an all-zero page. We want to
	 * recycle all-zero pages, not fail.  Also, we want to use a nondefault
	 * buffer access strategy.
	 */
	buf = ReadBufferExtended(rel, MAIN_FORKNUM, blkno, RBM_NORMAL,
							 info->strategy);
	LockBuffer(buf, BT_READ);
	page = BufferGetPage(buf);
	if (!PageIsNew(page))
	{
		_bt_checkpage(rel, buf);
		opaque = (BTPageOpaque) PageGetSpecialPointer(page);
	}

	/*
	 * If we are recursing, the only case we want to do anything with is a
	 * live leaf page having the current vacuum cycle ID.  Any other state
	 * implies we already saw the page (eg, deleted it as being empty).
	 */
	if (blkno != orig_blkno)
	{
		if (_bt_page_recyclable(page) ||
			P_IGNORE(opaque) ||
			!P_ISLEAF(opaque) ||
			opaque->btpo_cycleid != vstate->cycleid)
		{
			_bt_relbuf(rel, buf);
			return;
		}
	}

	/* Page is valid, see what to do with it */
	if (_bt_page_recyclable(page))
	{
		/* Okay to recycle this page */
		RecordFreeIndexPage(rel, blkno);
		vstate->totFreePages++;
		stats->pages_deleted++;
	}
	else if (P_ISDELETED(opaque))
	{
		/* Already deleted, but can't recycle yet */
		stats->pages_deleted++;
	}
	else if (P_ISHALFDEAD(opaque))
	{
		/* Half-dead, try to delete */
		delete_now = true;
	}
	else if (P_ISLEAF(opaque))
	{
		OffsetNumber deletable[MaxOffsetNumber];
		int			ndeletable;
		OffsetNumber offnum,
					minoff,
					maxoff;

		/*
		 * Trade in the initial read lock for a super-exclusive write lock on
		 * this page.  We must get such a lock on every leaf page over the
		 * course of the vacuum scan, whether or not it actually contains any
		 * deletable tuples --- see nbtree/README.
		 */
		LockBuffer(buf, BUFFER_LOCK_UNLOCK);
		LockBufferForCleanup(buf);

		//省略
		/*
		 * Scan over all items to see which ones need deleted according to the
		 * callback function.
		 */
		ndeletable = 0;
		minoff = P_FIRSTDATAKEY(opaque);
		maxoff = PageGetMaxOffsetNumber(page);
		if (callback)
		{
            //步骤1：遍历页面内索引元组，判断元组是否可以删除。
			for (offnum = minoff;
				 offnum <= maxoff;
				 offnum = OffsetNumberNext(offnum))
			{
				IndexTuple	itup;
				ItemPointer htup;

				itup = (IndexTuple) PageGetItem(page,
												PageGetItemId(page, offnum));
				htup = &(itup->t_tid);

                //步骤2：使用deletable数组记录需要删除的元组。
				if (callback(htup, callback_state))
					deletable[ndeletable++] = offnum;
			}
		}

		/*
		 * Apply any needed deletes.  We issue just one _bt_delitems_vacuum()
		 * call per page, so as to minimize WAL traffic.
		 */
		if (ndeletable > 0)
		{
			/* 步骤3：调用_bt_delitems_vacuum删除deletable中的元组
			 */
			_bt_delitems_vacuum(rel, buf, deletable, ndeletable,
								vstate->lastBlockVacuumed);

			/*
			 * Remember highest leaf page number we've issued a
			 * XLOG_BTREE_VACUUM WAL record for.
			 */
			if (blkno > vstate->lastBlockVacuumed)
				vstate->lastBlockVacuumed = blkno;

			stats->tuples_removed += ndeletable;
			/* must recompute maxoff */
			maxoff = PageGetMaxOffsetNumber(page);
		}
		else
		{
			/*
			 * If the page has been split during this vacuum cycle, it seems
			 * worth expending a write to clear btpo_cycleid even if we don't
			 * have any deletions to do.  (If we do, _bt_delitems_vacuum takes
			 * care of this.)  This ensures we won't process the page again.
			 *
			 * We treat this like a hint-bit update because there's no need to
			 * WAL-log it.
			 */
			if (vstate->cycleid != 0 &&
				opaque->btpo_cycleid == vstate->cycleid)
			{
				opaque->btpo_cycleid = 0;
				MarkBufferDirtyHint(buf, true);
			}
		}

		/*
		 * If it's now empty, try to delete; else count the live tuples. We
		 * don't delete when recursing, though, to avoid putting entries into
		 * freePages out-of-order (doesn't seem worth any extra code to handle
		 * the case).
		 */
		if (minoff > maxoff)
			delete_now = (blkno == orig_blkno);
		else
			stats->num_index_tuples += maxoff - minoff + 1;
	}

	if (delete_now)
	{
		MemoryContext oldcontext;
		int			ndel;

		/* Run pagedel in a temp context to avoid memory leakage */
		MemoryContextReset(vstate->pagedelcontext);
		oldcontext = MemoryContextSwitchTo(vstate->pagedelcontext);

		ndel = _bt_pagedel(rel, buf);

		/* count only this page, else may double-count parent */
		if (ndel)
			stats->pages_deleted++;

		MemoryContextSwitchTo(oldcontext);
		/* pagedel released buffer, so we shouldn't */
	}
	else
		_bt_relbuf(rel, buf);

	/*
	 * This is really tail recursion, but if the compiler is too stupid to
	 * optimize it as such, we'd eat an uncomfortably large amount of stack
	 * space per recursion level (due to the deletable[] array). A failure is
	 * improbable since the number of levels isn't likely to be large ... but
	 * just in case, let's hand-optimize into a loop.
	 */
	if (recurse_to != P_NONE)
	{
		blkno = recurse_to;
		goto restart;
	}
}

_bt_delitems_vacuum

我们再来看看_bt_delitems_vacuum函数的实现。_bt_delitems_vacuum的核心是PageIndexMultiDelete函数，PageIndexMultiDelete有两个步骤：

  • 清理索引元组的ItemData

    清理ItemData的方式是，通过deletable数组获取不用清理的ItemData，存放在newitemids数组中，然后直接将newitemids拷贝到索引页面的pd_linp数组中。

  • 调用compactify_tuples清理索引元组的元组实体

    compactify_tuples在《PostgreSQL Vacuum—元组删除》中已经介绍过了，此处不再赘述。

索引插入

处理Vacuum，还有一种索引删除的场景，是在向索引执行插入操作时，如果发现待插入的页面没有足够的空闲空间，会先尝试对页面进行空间整理，具体代码如下：

//nbtinsert.c line 605
movedright = false;
vacuumed = false;
while (PageGetFreeSpace(page) < itemsz)
{
    Buffer		rbuf;
    BlockNumber rblkno;

    /*
	 * before considering moving right, see if we can obtain enough space
	 * by erasing LP_DEAD items
	 */
    if (P_ISLEAF(lpageop) && P_HAS_GARBAGE(lpageop))
    {
        _bt_vacuum_one_page(rel, buf, heapRel);

        /*
		 * remember that we vacuumed this page, because that makes the
		 * hint supplied by the caller invalid
		 */
        vacuumed = true;

        if (PageGetFreeSpace(page) >= itemsz)
            break;			/* OK, now we have enough space */
    }
}

_bt_vacuum_one_page负责页面空间整理，主要有两个步骤：

  • 步骤1：遍历页面内所有索引元组，记录标记为LP_DEAD的索引元组，存放在deletable中。
  • 步骤2：调用_bt_delitems_delete删除deletable中的元组。

_bt_vacuum_one_page实现如下：

static void
_bt_vacuum_one_page(Relation rel, Buffer buffer, Relation heapRel)
{
	OffsetNumber deletable[MaxOffsetNumber];
	int			ndeletable = 0;
	OffsetNumber offnum,
				minoff,
				maxoff;
	Page		page = BufferGetPage(buffer);
	BTPageOpaque opaque = (BTPageOpaque) PageGetSpecialPointer(page);

	/*
	 * Scan over all items to see which ones need to be deleted according to
	 * LP_DEAD flags.
	 * 步骤1：遍历页面内所有索引元组，记录**标记为LP_DEAD**的索引元组，存放在deletable中。
	 */
	minoff = P_FIRSTDATAKEY(opaque);
	maxoff = PageGetMaxOffsetNumber(page);
	for (offnum = minoff;
		 offnum <= maxoff;
		 offnum = OffsetNumberNext(offnum))
	{
		ItemId		itemId = PageGetItemId(page, offnum);

		if (ItemIdIsDead(itemId))
			deletable[ndeletable++] = offnum;
	}

	if (ndeletable > 0)
		_bt_delitems_delete(rel, buffer, deletable, ndeletable, heapRel);

	/*
	 * Note: if we didn't find any LP_DEAD items, then the page's
	 * BTP_HAS_GARBAGE hint bit is falsely set.  We do not bother expending a
	 * separate write to clear it, however.  We will clear it when we split
	 * the page.
	 */
}

_bt_delitems_delete和前面讲过的_bt_delitems_vacuum十分相似，本质都是调用PageIndexMultiDelete，这里就不在赘述了。在这里我们需要重点解决的问题是：索引元组是在什么时候如何被标记为LP_DEAD的？

索引元组的LP_DEAD标记

基本流程

索引元组的LP_DEAD是在索引遍历时标记的，我们先来回顾下索引遍历的流程：

  • 步骤1：对索引页面加共享锁。
  • 步骤2：遍历索引页面获取满足索引条件的所有索引元组，存放到本地缓存中（index tuple array）。
  • 步骤3：对索引页面解锁。
  • 步骤4：遍历index tuple array，通过index tuple找到数据元组，判断元组可见性、正确性。
  • 步骤5：遍历完一个页面，就移动到下一个页面，重复步骤1~步骤4。

在步骤4中，我们会判断数据元组的可见的性，也就是遍历元组的HOT链，找到一个可见的版本。其实在这个时候，我们就可以得知HOT链上的元组是否全部过期？如果是就表示相应的索引元组可以被删除了，这个索引元组就可以被标记为LP_DEAD！

而在实际实现时，PostgreSQL会使用killedItems数组缓存需要标记为LP_DEAD的元组，在遍历下一个页面（也就是步骤5）之前，来统一对这些元组加LP_DEAD标记。关于加LP_DEAD标记，我们需要注意以下几点：

  • 对页面加共享锁

    由于在前面步骤3的时候，我们已经对页面进行了解锁，所以此时需要再次对页面加共享锁。对你没有看错，是共享锁！因为修改ItemData的标记只会涉及4字节的修改（准确的说是4字节中的两位），而4字节读写本来就是原子的，所以可以并发执行。

  • 并发分裂

    在遍历index tuple array的过程中，页面可能发生分裂。所以在给元组加LP_DEAD标记时，不能保证index tuple array中的所有元组都能在页面中找到（甚至可能全都找不到）。不过这没有关系，元组的可见性正确性都只由元组本身决定，索引删不删不影响正确性。

  • XLOG

    既然索引删不删不影响正确定，那么给索引元组加LP_DEAD标记也不需要写XLOG。

代码实现

下面我们看看上述流程的相关代码。

index_getnext

index_getnext是索引遍历的主要循环，主要有两个步骤：

  • 步骤1：获取一条索引元组
  • 步骤2：通过索引元组获取数据元组
HeapTuple
index_getnext(IndexScanDesc scan, ScanDirection direction)
{
	HeapTuple	heapTuple;
	ItemPointer tid;

	for (;;)
	{
		if (scan->xs_continue_hot)
		{
			/*
			 * We are resuming scan of a HOT chain after having returned an
			 * earlier member.  Must still hold pin on current heap page.
			 */
			Assert(BufferIsValid(scan->xs_cbuf));
			Assert(ItemPointerGetBlockNumber(&scan->xs_ctup.t_self) ==
				   BufferGetBlockNumber(scan->xs_cbuf));
		}
		else
		{
			/* Time to fetch the next TID from the index */
            //步骤1：获取一条索引元组
			tid = index_getnext_tid(scan, direction);

			/* If we're out of index entries, we're done */
			if (tid == NULL)
				break;
		}

		/*
		 * Fetch the next (or only) visible heap tuple for this index entry.
		 * If we don't find anything, loop around and grab the next TID from
		 * the index.
		 * 步骤2：通过索引元组获取数据元组
		 */
		heapTuple = index_fetch_heap(scan);
		if (heapTuple != NULL)
			return heapTuple;
	}

	return NULL;				/* failure exit */
}

index_fetch_heap

在获取数据元组时，我们会判断数据元组HOT链上的所有元组是否都过期了，index_fetch_heap的主要代码如下：

HeapTuple
index_fetch_heap(IndexScanDesc scan)
{
	ItemPointer tid = &scan->xs_ctup.t_self;
	bool		all_dead = false;
	bool		got_heap_tuple;

	/* Obtain share-lock on the buffer so we can examine visibility */
	LockBuffer(scan->xs_cbuf, BUFFER_LOCK_SHARE);
	got_heap_tuple = heap_hot_search_buffer(tid, scan->heapRelation,
											scan->xs_cbuf,
											scan->xs_snapshot,
											&scan->xs_ctup,
											&all_dead,
											!scan->xs_continue_hot);
	LockBuffer(scan->xs_cbuf, BUFFER_LOCK_UNLOCK);

	if (!scan->xactStartedInRecovery)
		scan->kill_prior_tuple = all_dead;

	return NULL;
}

heap_hot_search_buffer负责遍历HOT链判断HOT链上元组是否过期，如果元组均过期all_dead就为TRUE，表示该索引元组需要标记为LP_DEAD。

btgettuple

再次进入index_getnext_tid时，就会将这条索引元组加入killedItems数组，实现代码如下：

//nbtree.c line:332
//调用顺序：index_getnext_tid -> btgettuple
if (scan->kill_prior_tuple)
{
    if (so->killedItems == NULL)
        so->killedItems = (int *)
        palloc(MaxIndexTuplesPerPage * sizeof(int));
    if (so->numKilled < MaxIndexTuplesPerPage)
        so->killedItems[so->numKilled++] = so->currPos.itemIndex;
}

_bt_steppage

在访问下一个页面之前，会为killedItems数组中记录的索引元组加上LP_DEAD标记，代码如下：

//nbtree.c line:1302
//调用顺序：index_getnext_tid -> btgettuple -> _bt_next -> _bt_steppage
static bool
_bt_steppage(IndexScanDesc scan, ScanDirection dir)
{
	BTScanOpaque so = (BTScanOpaque) scan->opaque;
	Relation	rel;
	Page		page;
	BTPageOpaque opaque;

	Assert(BTScanPosIsValid(so->currPos));

	/* Before leaving current page, deal with any killed items */
	if (so->numKilled > 0)
		_bt_killitems(scan);
    //省略
}

_bt_killitems

最后，我们来看看_bt_killitems的代码实现：

void
_bt_killitems(IndexScanDesc scan)
{
	BTScanOpaque so = (BTScanOpaque) scan->opaque;
	Page		page;
	BTPageOpaque opaque;
	OffsetNumber minoff;
	OffsetNumber maxoff;
	int			i;
	int			numKilled = so->numKilled;
	bool		killedsomething = false;

	Assert(BTScanPosIsValid(so->currPos));

	/*
	 * Always reset the scan state, so we don't look for same items on other
	 * pages.
	 */
	so->numKilled = 0;

	if (BTScanPosIsPinned(so->currPos))
	{
		/*
		 * We have held the pin on this page since we read the index tuples,
		 * so all we need to do is lock it.  The pin will have prevented
		 * re-use of any TID on the page, so there is no need to check the
		 * LSN.
		 */
		LockBuffer(so->currPos.buf, BT_READ);

		page = BufferGetPage(so->currPos.buf);
	}
	else
	{
		Buffer		buf;

		/* Attempt to re-read the buffer, getting pin and lock. */
        //步骤1：给页面加共享锁
		buf = _bt_getbuf(scan->indexRelation, so->currPos.currPage, BT_READ);

		/* It might not exist anymore; in which case we can't hint it. */
		if (!BufferIsValid(buf))
			return;

		page = BufferGetPage(buf);
		if (BufferGetLSNAtomic(buf) == so->currPos.lsn)
			so->currPos.buf = buf;
		else
		{
			/* Modified while not pinned means hinting is not safe. */
			_bt_relbuf(scan->indexRelation, buf);
			return;
		}
	}

	opaque = (BTPageOpaque) PageGetSpecialPointer(page);
	minoff = P_FIRSTDATAKEY(opaque);
	maxoff = PageGetMaxOffsetNumber(page);

    //步骤2：在页面中查找killedItems中的每一条元组，如果找到就加上LP_DEAD标记
	for (i = 0; i < numKilled; i++)
	{
		int			itemIndex = so->killedItems[i];
		BTScanPosItem *kitem = &so->currPos.items[itemIndex];
		OffsetNumber offnum = kitem->indexOffset;

		Assert(itemIndex >= so->currPos.firstItem &&
			   itemIndex <= so->currPos.lastItem);
		if (offnum < minoff)
			continue;			/* pure paranoia */
		while (offnum <= maxoff)
		{
			ItemId		iid = PageGetItemId(page, offnum);
			IndexTuple	ituple = (IndexTuple) PageGetItem(page, iid);

			if (ItemPointerEquals(&ituple->t_tid, &kitem->heapTid))
			{
				/* found the item */
				ItemIdMarkDead(iid);
				killedsomething = true;
				break;			/* out of inner search loop */
			}
			offnum = OffsetNumberNext(offnum);
		}
	}

	/*
	 * Since this can be redone later if needed, mark as dirty hint.
	 *
	 * Whenever we mark anything LP_DEAD, we also set the page's
	 * BTP_HAS_GARBAGE flag, which is likewise just a hint.
	 */
	if (killedsomething)
	{
		opaque->btpo_flags |= BTP_HAS_GARBAGE;
		MarkBufferDirtyHint(so->currPos.buf, true);
	}

    //步骤3：解锁
	LockBuffer(so->currPos.buf, BUFFER_LOCK_UNLOCK);
}
obvious__
关注
  • 5
    点赞
  • 踩
  • 5
    收藏
    觉得还不错? 一键收藏
  • 1
    评论
专栏目录
PostgreSQL-Vacuum
u014440880的博客
07-10 716
Postgresql表中隐藏字段 -oid: 行的对象标识符，创建表的时候使用了with oid，或者是设置了default_with_oids 配置参数时出现； -tableoid：包含本行的表的 OID。 -xmin：插入该行版本的事务的标识（事务 ID）； -xmax：删除事务的标识（事务ID），如果不是被删除的行版本，那么是零； -cmin：插入事务内部的命令标识，从0开始； -cmax：删除...
PostgreSQL中的VACUUM
深海微澜
04-15 9335
最近搞了一个公众号PostgreSQL运维技术，欢迎来踩~ 悄悄放一张： PostgreSQL运维技术 我在之前的一篇介绍MVCC的文章中提到，MVCC有事务ID回卷的问题，它的解决方案是VACUUM。但是没有展开讲。这章的话，会详细地介绍下VACUUM。 VACUUM的两个主要任务是删除死亡元组和冻结事务ID。 为了删除死亡元组，VACUUM提供了两种模式，即Concurrent Vacuum和Full Vacuum。 Concurrent Vacuum通常简称为VACUUM。...
PostgreSQL B+树索引---页面删除
obvious__的博客
08-18 2386
本文将阐述PostgreSQL B*树索引的最后一个部分，索引的页面删除。该部分内容在《PostgreSQL Blink-tree ReadMe—翻译》中其实已经涉及到了，不过Read Me的内容较多，本文将重新梳理一下B*树索引页面删除的逻辑，并从源代码的角度分析PostgreSQL如何实现页面删除。在PostgreSQL中，VACUUM操作会对B*树中的索引元组进行物理删除，当一个索引页面中的所有元组都被删除，即索引页面被删空后，VACUUM操作会将这个页面从B*树中删除。...
PostgreSQL 清理过程
yunmu666的博客
01-31 2049
清理过程
怎样在 PostgreSQL 中优化对大表的索引删除和重建策略？
最新发布
发现生活，分享智慧，一起成长！
07-16 794
在数据库中，当一个表的数据量非常大，达到数十万、数百万甚至数千万条记录时，我们就可以称之为大表。处理大表时，数据库的性能可能会受到影响，因为查询、插入、更新和删除操作都需要花费更多的时间和资源。打个比方，大表就像是一个巨大的仓库，里面存放着大量的货物。要在这个仓库中找到特定的货物（数据），就需要花费更多的时间和精力。在 PostgreSQL 中优化对大表的索引删除和重建策略是一项非常重要的任务，它需要我们对数据库的性能有深入的理解，对业务需求有清晰的认识，以及对操作过程有精细的控制。
PostGIS系列课程之空间索引
专注GIS软件开发。
09-26 1410
空间索引 回想一下，空间索引是空间数据库的三个关键功能之一。索引使使用空间数据库处理大型数据集成为可能。如果不建立索引，则对功能的任何搜索都将需要对数据库中的每个记录进行“顺序扫描”。通过将数据组织到可以快速遍历以查找特定记录的搜索树中，可以加快索引的搜索速度。 空间索引是PostGIS的最大能力之一。在前面的示例中，建立空间联接需要将整个表相互比较。这可能会非常耗时：将两个10,000条记录的表连接起来，每个表没有索引将需要100,000,000个比较；使用索引的成本可能低至20,000次比较。 当我
PostgreSQL 索引管理
分享既学习
06-30 1798
索引是关系型数据库离不开的话题，它是数据库中一种快速查询数据的方法。在 SQL 优化中，创建高性能的索引非常重要，本篇文章将对比 MySQL 介绍 PostgreSQL 的索引管理。
千万级大表如何更快速的创建索引_Java架构师-面试官出的MySQL索引问题，这篇文章全给你解决...
weixin_39817176的博客
11-29 1052
0 前言这篇文章不会讲解索引的基础知识，主要是关于MySQL数据库的B+树索引的相关原理，里面的一些知识都参考了MySQL技术内幕这本书，也算对于这些知识的总结。对于B树和B+树相关的知识，可以参考我的这篇博客：面试官问你B树和B+树，就把这篇文章丢给他1 索引的管理索引有很多中类型：普通索引、唯一索引、主键索引、组合索引、全文索引，下面我们看看如何创建和删除下面这些类型的索引。1.1 索引的创建...
postgresql-13.0.tar.gz
01-18
5. **自动VACUUM**：自动VACUUM进程得到了改进，现在能够更智能地识别和处理不再使用的数据，从而保持数据库的高效运行。 6. **更好的JSON支持**：PostgreSQL 13进一步加强了对JSON数据类型的支持，提供了更多内建...
postgresql-9.5.0-1-windows 32位
09-27
PostgreSQL是一种开源关系型数据库管理系统（RDBMS），在IT领域广泛应用，特别是在需要高度可靠性和复杂查询的场景中。此“postgresql-9.5.0-1-windows 32位”压缩包是针对Windows操作系统32位架构的PostgreSQL ...
postgresql-11.2.1win64.zip
04-24
2. **并行操作增强**：PostgreSQL 11引入了更多的并行化操作，如并行扫描、索引构建和VACUUM，这些改进进一步提升了多核CPU环境下的性能。 3. **存储过程语言支持**：PostgreSQL支持多种存储过程语言，如PL/pgSQL，...
xxl-job-master-postgresql.zip
12-09
8. **监控与维护**：PostgreSQL的监控工具如pgAdmin、pgBadger等可以用于监控XXL-JOB的数据性能和健康状态，定期进行数据库维护工作，如 vacuum、reindex 等。 9. **测试与验证**：迁移后，必须进行详尽的单元测试...
postgresql-9.6.0.tar.gz
10-21
- **快速的B树索引**：更新了B树索引算法，使得插入和删除操作更快。 - **即时冻结**：改进了VACUUM机制，减少数据库文件的增长，避免XID-wraparound问题。 - **逻辑复制**：初步实现了逻辑复制功能，支持订阅/...
第六章：死磕postgreSQL，10个问题带你了解PostgreSQL的索引使用
qq_28245087的博客
07-10 1915
数据库索引是一种数据结构，用于提高数据库查询的速度和效率。它类似于书籍的目录，可以帮助数据库系统快速找到需要的数据，而无需遍历整个数据库。索引是根据一个或多个列的值创建的，这些列通常是经常被查询的列。通过使用索引，数据库可以更快地定位到满足查询条件的数据行，从而提高查询性能。索引可以在查询过程中减少磁盘I/O操作的次数，因为数据库系统可以直接跳过不满足查询条件的数据块，而只读取包含所需数据的数据块。然而，索引也需要占用一定的存储空间，并且在写入数据时会有一定的性能开销。
五、MySql索引基本介绍
Jian Sun_的博客
09-14 962
上篇文章介绍了查询命令中过慢的语句，总结原因如下： 查询命令过慢的原因： 在执行时需要对所有的数据来进行排序 在执行时需要对表中所有数据进行遍历 通过I/O流加载表文件次数 索引介绍： 【定义】： 索引存在于对应的索引文件中，索引本质就是排好了顺序的一组数据 【作用】： 在索引数据中进行排序时，避免再次排序 在索引数据中对数据行进行定位时，可以避免全表扫面 【索引文件位置】： 如果当前的表依赖于innodb存储引擎，索引存在于FRM文件中 如果当前的表依赖于myisam存储引擎，所以.
PostgreSQL11 | 索引
红星编程实验室
05-10 4518
本文根据原书《PostgreSql11 从入门到精通》（清华大学出版社）第9章总结整理，为提问与解答可以帮助更多人，本博客模拟GitHub的issue方案，所以私信已关，有问题请在评论区直接指正与提问，允许转发、复制或引用本文章，必须遵守开源法则注释来源与作者，感谢您的阅读
postgresql 获取表的字段及创建表、添加、删除、编辑字段语句
热门推荐
keepstudy_yangzh的博客
04-24 1万+
添加字段 ALTER TABLE data_u11001000504 ADD COLUMN filedtest1 INTEGER 字段类型可以为：INTEGER、int4 int8、 varchar(11) 编辑字段 （1）修改字段类型 ALTER TABLE data_u11001000504 ALTER COLUMN varch TYPE int4 USING(varch::int...
access建立两个字段唯一索引_一文读懂MySQL索引，面试遇到这类问题就不是问题了...
weixin_39715460的博客
10-27 615
一、索引的作用一般的应用系统，读写比例在10:1左右，而且插入操作和一般的更新操作很少出现性能问题，遇到最多的，也是最容易出问题的，还是一些复杂的查询操作，所以查询语句的优化显然是重中之重。在数据量和访问量不大的情况下，mysql访问是非常快的，是否加索引对访问影响不大。但是当数据量和访问量剧增的时候，就会发现mysql变慢，甚至down掉，这就必须要考虑优化sql了，给数据库建立正确合理的索引，...
评论 1
添加红包

请填写红包祝福语或标题

个

红包个数最小为10个

元

红包金额最低5元

当前余额3.43元 前往充值 >
需支付：10.00元
成就一亿技术人!
领取后你会自动成为博主和红包主的粉丝 规则
hope_wisdom
发出的红包
实付元
使用余额支付
点击重新获取
扫码支付
钱包余额 0

抵扣说明：

1.余额是钱包充值的虚拟货币，按照1:1的比例进行支付金额的抵扣。
2.余额无法直接购买下载，可以购买VIP、付费专栏及课程。

余额充值