On Sunday, March 23, 2025, Marcelo Fernandes wrote:
> Hi folks,
>
> I came up with three strategies to verify whether a table is empty.
3 is strictly terrible worse to answer “is live row count > 0”.
Using an index likely serves no/negative benefit since it contains no tuple
liveness informati
Hi folks,
I came up with three strategies to verify whether a table is empty.
I wanted to sound the community to check whether my assumptions are correct for
each of these strategies, and to also discuss which strategy is best.
## Strategy 1 [possibly best?]
SELECT EXISTS (SELECT 1 FROM foo LIM
On Sunday, March 23, 2025, David G. Johnston
wrote:
>
> Maybe IOS helps though I do wonder whether a sequential scan skips over
> known all-dead pages making that relative benefit go away.
>
Well, no, since it tracks known visible, not known non-visible, though for
something like a fast exists t
> On Mar 23, 2025, at 21:15, David G. Johnston
> wrote:
>
> No idea if we take that shortcut.
I remember looking into that not too long ago, and the answer's no.
On Sunday, March 23, 2025, Christophe Pettus wrote:
>
> (And to be pedantic, #1 returns TRUE / FALSE while #2 returns /
> NULL, so they aren't exactly equivalent. If you are able to handle /
> NULL, you don't need the EXISTS clause.)
>
Leaving the limit in place, without exists #1 returns eit
> On Mar 23, 2025, at 20:42, Marcelo Fernandes wrote:
> Cons:
> 1. Sequential Scan
> 2. If the table is bloated, it reads more buffers.
These concerns probably sound worse than they really are. Assuming the table
is being vacuumed reliably, and is receiving inserts, those inserts will tend
