Marti Raudsepp wrote:
Another advantage of Oracle's approach seems that they need much less
tuple-level overhead. IMO the 23-byte tuple overhead is a much bigger
drawback in Postgres than table fragmentation.
Regards,
Marti
Oracle, however, does have a problem with "ORA-1555 Snapshot too o
On Thu, Nov 11, 2010 at 3:43 AM, wrote:
>> Okay, I want to know how the planner computes the cost of constructing
>> bitmap. And when the planner computes the cost of 'Bitmap Index Scan', if
>> it considers the influence of memory cache? As when I do not clear the
>> memory cache, I find the 'Bit
Robert Haas writes:
> Yeah, I'm not familiar with the logic in that area of the code, so I
> can't comment all that intelligently. However, I feel like there's a
> class of things that could potentially be optimized if we know that
> the only snapshot they could affect is the one we're currently
On Sat, Nov 13, 2010 at 20:01, Tom Lane wrote:
> What's your basis for asserting he's uninterested? Please have a little
> patience.
My apologies, I was under the impression that he hadn't answered your
request, but he did in the -hackers thread.
Regards,
Marti
--
Sent via pgsql-performance m
On Thu, Nov 11, 2010 at 20:25, Kyriacos Kyriacou
wrote:
> By definition of MVCC, when an UPDATE is performed, PostgreSQL creates a
> new copy of the row in a new location.
> result is to have huge fragmentation on table space, unnecessary updates
> in all affected indexes, unnecessary costly I/O
On Sat, Nov 13, 2010 at 07:53, Craig Ringer wrote:
> Oracle's MVCC approach has its own costs. Like Pg's, those costs increase
> with update/delete frequency. Instead of table bloat, Oracle suffers from
> redo log growth (or redo log size management issues). Instead of increased
> table scan costs
