When grilled further on (Thu, 29 Apr 2004 11:21:51 -0700),
Josh Berkus <[EMAIL PROTECTED]> confessed:
> spins_per_delay was not beneficial. Instead, try increasing them, one step
> at a time:
>
> (take baseline measurement at 100)
> 250
> 500
> 1000
> 1500
> 2000
> 3000
> 5000
>
> ... until y
Joseph Shraibman <[EMAIL PROTECTED]> writes:
> INFO: "elog": found 0 removable, 12869411 nonremovable row versions in
> 196195 pages
> DETAIL: 0 dead row versions cannot be removed yet.
> There were 5 unused item pointers.
> 0 pages are entirely empty.
> CPU 31.61s/4.53u sec elapsed 1096.83 sec.
Manfred Koizar <[EMAIL PROTECTED]> writes:
> Yes, the visible-to-all flag would be set as a by-product of an index
> scan, if the heap tuple is found to be visible to all active
> transactions. This update is non-critical
Oh really? I think you need to think harder about the transition
condition
On Fri, 30 Apr 2004 19:46:24 +0200, Jochem van Dieten
<[EMAIL PROTECTED]> wrote:
>> While the storage overhead could be reduced to 1 bit (not a joke)
>
>You mean adding an isLossy bit and only where it is set the head
>tuple has to be checked for visibility, if it is not set the head
>tuple does
On Fri, 30 Apr 2004, Gary Doades wrote:
> Yes, you're right and I have done this just to prove to myself that it
> is the index scan that is the bottleneck. I have some complex SQL that
> executes very quickly with Postgres, similar to MSSQL, but the index
> scans in most of those only touch a f
On 30 Apr 2004 at 9:37, Kevin Barnard wrote:
>
> I was always under the impression that MSSQL used leaf and row level locking and
> therefore
> was not a concurrent, in the same sense that postgres is, database. It would still
> allow for
> concurrent connections and such but updates will get
On 30 Apr 2004 at 8:32, Jeff wrote:
>
> A better comparision query may be a simple "select a from mytable
> where a between foo and bar" to get an index scan. In that case its a
> straight up, vanilla index scan. Nothing else getting in the way.
>
Yes, you're right and I have done this ju
Manfred Koizar wrote:
On Wed, 28 Apr 2004 09:05:04 -0400, Tom Lane <[EMAIL PROTECTED]> wrote:
[ ... visibility information in index tuples ... ]
Storing that information would at least double the overhead space used
for each index tuple. The resulting index bloat would significantly
slow index ope
On Apr 30, 2004, at 3:01 AM, Gary Doades wrote:
[ pg query plan, etc ]
I wonder if other parts of the plan are affecting the speed.
I've recently run into a case where a merge join plan was chosen for
this query, which took 11 seconds to execute. Forcing it to pick a
nested loop join dropped it
On Thu, 29 Apr 2004 19:09:09 -0400, Joseph Shraibman
<[EMAIL PROTECTED]> wrote:
>How does the analyzer/planner deal with rows clustered together?
There's a correlation value per column. Just try
SELECT attname, correlation
FROM pg_stats
WHERE tablename = '...';
if you
On 30 Apr 2004 at 7:26, Dennis Bjorklund wrote:
> On Fri, 30 Apr 2004, Gary Doades wrote:
>
> > I should have also pointed out that MSSQL reported that same index scan
> > as taking 65% of the overall query time. It was just "faster". The
> > overall query took 103ms in MSSQL.
>
> Are your results
11 matches
Mail list logo
