Rusty Conover <[EMAIL PROTECTED]> writes:
> Absolutely, I'll attempt to run the test against the current CVS HEAD.
> Do I need to pg_dump and restore from 8.1.4?
Yup, fraid so.
regards, tom lane
---(end of broadcast)---
TIP
On Aug 4, 2006, at 8:15 PM, Tom Lane wrote:Rusty Conover <[EMAIL PROTECTED]> writes: Is there any inherent benefit of using a the IN operator versus joining a temporary table? Should they offer near equal performance? It appears bitmap scan's aren't done when matching across a small temporary t
Rusty Conover <[EMAIL PROTECTED]> writes:
> Is there any inherent benefit of using a the IN operator versus
> joining a temporary table? Should they offer near equal performance?
> It appears bitmap scan's aren't done when matching across a small
> temporary table.
I believe the problem you
Hi,
Is there any inherent benefit of using a the IN operator versus
joining a temporary table? Should they offer near equal performance?
It appears bitmap scan's aren't done when matching across a small
temporary table.
I have a temporary table with 5 integers in it that I'm matching
a
On Tue, Aug 01, 2006 at 08:42:23PM -0400, Alvaro Herrera wrote:
> J. Andrew Rogers wrote:
> >
> > On Aug 1, 2006, at 2:49 PM, Milen Kulev wrote:
> > >Is anyone using XFS for storing/retrieving relatively large amount
> > >of data (~ 200GB)?
> >
> >
> > Yes, we've been using it on Linux since
I agree that OCFS 2.0 is NOT a general purpose PG (or any other) solution. My recollection is that OCFS gave about 15% performance improvements (same as setting some aggressive switches on ext3). I assume OCFS has excellent crash safety with its default settings but we did not test this as of ye
> WRT seek performance, we're doing 2500 seeks per second on the
Sun/Thumper on 36 disks.
Luke,
Have you had time to run benchmarksql against it yet? I'm just curious
about the IO seeks/s vs. transactions/minute correlation...
/Mikael
---(end of broadcast)---
Tom Lane <[EMAIL PROTECTED]> writes:
> It's usually better to use partitioning rules that have something to
> do with the WHERE-clauses you'd be using anyway. For instance, try
> to partition on ranges.
I agree and tried to create new partitioned tables. But now I ran into
some other performance
