Just chiming in: I rely heavily on the current default behavior
because it prevents large statements pasted into psql that cause
errors in transactions from partially running, and if it were changed
I would have caused production outages.
On Wed, Mar 15, 2017 at 8:42 AM, Pavel Stehule wrote:
>
>
Yeah, you're right, I believe that every code path in VACUUM that
leads to the visibility map bit being set also leads to all remaining
tuples on the page being frozen. So in a world without heap pruning,
frozen should be a reliable proxy for "value of the tuple the last
time it was added to the
> VACUUM counter updates, on the other hand, initially seem more
> problematic, since if we grab the value of the counter, then VACUUM
> updates the counter and the visbility bits, and then we check which
> visibility bits are set, we might skip pages we really need to check
> (since we're using an
t> It seems to me this can't possibly work because of race conditions.
> In particular, what happens when some query dirties a page and thereby
> clears its fully-visible bit? Presumably, any such query would have
> to (1) recompute the number of all-visible rows on that page (already
> an expens
ltas.
On Fri, Apr 4, 2014 at 5:38 AM, Joshua Yanovski wrote:
> Hey all,
>
> First off, please feel free to let me know if this idea is a waste of time :)
>
> I was thinking about COUNT(*) and its slow performance today, and I
> thought about whether we could get better perfor
is worth pursuing further.
Thanks!
-- Joshua Yanovski
--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-hackers
> I'm glad you're looking at this, but we're in the final throws of
> nailing down 9.4 and I don't have anticipate I'll have time to look at
> it in the near future. You should add it here so we don't forget
> about it:
>
> https://commitfest.postgresql.org/action/commitfest_view/open
Yeah, no wor
Here's a SQL script that (1) demonstrates the new index only scan
functionality, and (2) at least on my machine, has a consistently
higher planning time for the version with my change than without it.
On Sun, Mar 16, 2014 at 5:08 AM, Joshua Yanovski wrote:
> Proof of concept initial p
e codebase, I'd really
appreciate it if people could help me figure out the best approach
here (and, more importantly, if one is necessary based on benchmarks).
And while this should go without saying, if this patch doesn't
actually work then please let me know, since all the above is based o
