Tom Lane wrote:
Joseph Shraibman [EMAIL PROTECTED] writes:
I have a table that is never updated, only INSERTED into. Is there a way
I can prevent vacuum wasting time on this table
What makes you think vacuum is wasting much time on this table? AFAICS
it will only update any unfixed hint bits
On 29 Apr 2004 at 19:17, Tom Lane wrote:
Josh Berkus [EMAIL PROTECTED] writes:
Certainly the fact that MSSQL is essentially a single-user database makes
things easier for them.
Our recent testing (cf the Xeon thread) says that the interlocking we
do to make the world safe for multiple
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 based on a
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
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
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 just to
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 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 few
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 not
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 you find an
10 matches
Mail list logo
