Given an index like this:
CREATE UNIQUE INDEX i1 ON t1 (c1) WHERE c1 IS NOT NULL;
and a query like this:
SELECT * FROM t1 WHERE c1 = 123;
I'd like the planner to be smart enough to use an index scan using i1.
Send a patch ;-)
The routine you want to teach about this is pred_test_simple_cl
On 03/03/2004 18:23 scott.marlowe wrote:
[snip]
There are three factors that affect how fast you can get to the next
sector:
seek time
settle time
rotational latency
Most drives only list the first, and don't bother to mention the other
two.
Ah yes, one of my (very) few still functioning brain cell
John Siracusa <[EMAIL PROTECTED]> writes:
> Given an index like this:
> CREATE UNIQUE INDEX i1 ON t1 (c1) WHERE c1 IS NOT NULL;
> and a query like this:
> SELECT * FROM t1 WHERE c1 = 123;
> I'd like the planner to be smart enough to use an index scan using i1.
Send a patch ;-)
The routine
Simon Riggs wrote:
On the other hand, I was just about to change the wal_debug behaviour to
allow better debugging of PITR features as they're added.
That's a development activity. Enabling the WAL_DEBUG #ifdef by
default during the 7.5 development cycle would be uncontroversial, I
think.
I thin
"Simon Riggs" <[EMAIL PROTECTED]> writes:
> The behaviour I wish to add is:
> Keep wal_debug as a value between 0 and 16.
> If =0 then no debug output (default).
> Use following bitmasks against the value
> Mask 1 = XLOG Checkpoints get logged
> Mask 2 = Archive API calls get logged
> Mask 4 = Tran
Josh Berkus wrote:
Hmmm. I was told that it was this way for 7.4 as well; that's why it's in
the docs that way.
No such statement is made in the docs AFAIK: they merely say "If
nonzero, turn on WAL-related debugging output."
I invented a new #ifdef symbol when making this change in CVS HEAD, s
> "FW" == Florian Weimer <[EMAIL PROTECTED]> writes:
FW> After increasing the number of checkpoint segments and the shared-memory
FW> buffers, performance is back to the expected levels. It might even be a
FW> bit faster.
If you've got the time, could you try also doing the full bulk insert
On Wed, 3 Mar 2004, Paul Thomas wrote:
>
> On 02/03/2004 23:25 johnn wrote:
> > [snip]
> > random_page_cost should be set with the following things taken into
> > account:
> > - seek speed
>
> Which is not exactly the same thing as spindle speed as it's a combination
> of spindle speed an
>Neil Conway
> Simon Riggs wrote:
> >>Josh Berkus wrote
> >>
> >>>Simon Riggs wrote
> >>>Please set WAL_DEBUG to 1 so we can see a bit more info: thanks.
> >>
> >>I'm pretty sure that WAL_DEBUG requires a compile-time option.
> >
> > I'm surprised, but you are right, the manual does SAY this requir
Would turning autocommit off help?
Vivek Khera wrote:
"FW" == Florian Weimer <[EMAIL PROTECTED]> writes:
FW> After increasing the number of checkpoint segments and the shared-memory
FW> buffers, performance is back to the expected levels. It might even be a
FW> bit faster.
If you've got the tim
On Mar 3, 2004, at 4:37 PM, Greg Spiegelberg wrote:
Would turning autocommit off help?
doubtful, since the bulk insert is all one transaction.
---(end of broadcast)---
TIP 4: Don't 'kill -9' the postmaster
Neil,
> Actually, the manual is correct: in 7.4 and earlier releases, enabling
> wal_debug can be done without also setting a compile-time #ifdef. As
> of current CVS HEAD, the WAL_DEBUG #ifdef must be defined before this
> variable is available.
Hmmm. I was told that it was this way for 7.4
Vivek,
> > With large RAID, have you found that having WAL on a seperate array
> > actually
> > boosts performance? The empirical tests we've seen so far don't seem
> > to
> > support this.
>
> Yes, it was a noticeable improvement.
Do you have any stats? This would be useful for your talk,
John,
> This would imply that an upgrade in drive RPM should be accompanied by
> a decrease in random_page_cost, correct?
Maybe. Maybe not. Tom's Hardware did some Bonnie++ testing with a variety
of new drives last year. They were moderately surprised to find that there
were "faster" drive
Florian Weimer wrote:
> After an upgrade to 7.4.1 (from 7.3) we see a severe performance
> regression in bulk INSERTs.
In turns out that we were running the default configuration, and not the
tuned one in /etc/postgresql. *blush*
After increasing the number of checkpoint segments and the shared-
On Tue, Mar 02, 2004 at 04:50:04PM -0500, Anjan Dave wrote:
> time/resources to do extensive testing, I am not sure if
> Postgres/Solaris9 is really suggested by the community for
> high-performance, as opposed to a XEON/Linux setup. Storage being a
> separate discussion.
I can tell you from expe
After an upgrade to 7.4.1 (from 7.3) we see a severe performance
regression in bulk INSERTs.
This is apparently caused by constant checkpointing (every 10 to 20
seconds). I've already increased the number of checkpoint segments to
32, but currently, there are just 10 or 11 files in the pg_xlog
di
On 02/03/2004 23:25 johnn wrote:
[snip]
random_page_cost should be set with the following things taken into
account:
- seek speed
Which is not exactly the same thing as spindle speed as it's a combination
of spindle speed and track-to-track speed. I think you'll find that a 15K
rpm disk, wh
18 matches
Mail list logo
