Tom Lane wrote:
Craig James [EMAIL PROTECTED] writes:
This seems like a bug to me, but it shows up as a performance problem.
emol_warehouse_1= explain analyze select version_id, parent_id from version
where version_id = 999;
If you actually *need* so many 9's here
On 6/26/08, Craig James [EMAIL PROTECTED] wrote:
This seems like a bug to me, but it shows up as a performance problem.
Since the column being queried is an integer, the second query (see below)
can't possibly match, yet Postgres uses a typecast, forcing a full table
scan for a value that
On Thu, Jun 26, 2008 at 9:02 AM, Frank Joerdens [EMAIL PROTECTED] wrote:
Which version are you using? 8.3 removes a lot of implicit casts (all?
not sure), so this may already be your fix.
8.3 only removed implicit casts from non text types to text (date -
text, int - text, interval - text...)
I know the problem, because there are about 35 million rows , which
cost about 12G disk space and checkpoint segments use 64, but update
operation is in one transaction which lead fast fill up the checkpoint
segments and lead do checkpoints frequently, but checkpoints will cost lots
2008/6/26 jay [EMAIL PROTECTED]:
If we can do commit very 1000 row per round, it may resolve the
problem.
But PG not support transaction within function yet?
Yeah, transaction control is not supported inside functions. There are
some hacks using dblink to do transactions inside
jay wrote:
I know the problem, because there are about 35 million rows , which
cost about 12G disk space and checkpoint segments use 64, but update
operation is in one transaction which lead fast fill up the checkpoint
segments and lead do checkpoints frequently, but checkpoints will
Hi -
I have been following this thread and find some of the recommendations
really surprising. I understand that MVCC necessarily creates overhead,
in-place updates would not be safe against crashes etc. but have a hard
time believing that this is such a huge problem for RDBMS in 2008. How do
Holger Hoffstaette wrote:
Hi -
I have been following this thread and find some of the recommendations
really surprising. I understand that MVCC necessarily creates overhead,
in-place updates would not be safe against crashes etc. but have a hard
time believing that this is such a huge problem
I've seen some concerns about buying database performance hardware
from DELL. Are there at least some of the RAID cards that work well
with Linux or should I stay clear of DELL permanently?
Thanks!
//Henke
25 jun 2008 kl. 17.45 skrev Greg Smith:
On Wed, 25 Jun 2008, Henrik wrote:
Would
On Wed, 25 Jun 2008, Andrew Sullivan wrote:
the key thing to do is to ensure you have good testing infrastructure in
place to check that things will work before you deploy to production.
This is true whether you're using Linux or completely closed source
software. There are two main
On Jun 25, 2008, at 11:35 AM, Matthew Wakeling wrote:
On Wed, 25 Jun 2008, Greg Smith wrote:
A firewire-attached log device is an extremely bad idea.
Anyone have experience with IDE, SATA, or SAS-connected flash
devices like the Samsung MCBQE32G5MPP-0VA? I mean, it seems lovely -
32GB,
On Thu, Jun 26, 2008 at 02:40:59PM +0200, Holger Hoffstaette wrote:
large databases treat mass updates? AFAIK both DB2 and Oracle use MVCC
(maybe a different kind?) as well, but I cannot believe that large updates
still pose such big problems.
DB2 does not use MVCC. This is why lock
On Thu, Jun 26, 2008 at 09:16:25PM +0800, Craig Ringer wrote:
I think Pg already does in place updates, or close, if the tuples being
replaced aren't referenced by any in-flight transaction. I noticed a while
ago that if I'm doing bulk load/update work, if there aren't any other
Holger Hoffstaette wrote:
Hi -
I have been following this thread and find some of the recommendations
really surprising. I understand that MVCC necessarily creates overhead,
in-place updates would not be safe against crashes etc. but have a hard
time believing that this is such a huge problem
jay [EMAIL PROTECTED] writes:
I know the problem, because there are about 35 million rows , which
cost about 12G disk space and checkpoint segments use 64, but update
operation is in one transaction which lead fast fill up the checkpoint
segments and lead do checkpoints frequently, but
2008/6/26 Pavan Deolasee [EMAIL PROTECTED]:
2008/6/26 jay [EMAIL PROTECTED]:
If we can do commit very 1000 row per round, it may resolve the
problem.
But PG not support transaction within function yet?
Yeah, transaction control is not supported inside functions. There are
some
2008/6/26 Tom Lane [EMAIL PROTECTED]:
jay [EMAIL PROTECTED] writes:
I know the problem, because there are about 35 million rows , which
cost about 12G disk space and checkpoint segments use 64, but update
operation is in one transaction which lead fast fill up the checkpoint
segments
On Thu, 26 Jun 2008, Vivek Khera wrote:
Anyone have experience with IDE, SATA, or SAS-connected flash devices like
the Samsung MCBQE32G5MPP-0VA? I mean, it seems lovely - 32GB, at a transfer
rate of 100MB/s, and doesn't degrade much in performance when writing small
random blocks. But what's
On Thu, Jun 26, 2008 at 10:14 AM, Matthew Wakeling [EMAIL PROTECTED] wrote:
On Thu, 26 Jun 2008, Vivek Khera wrote:
Anyone have experience with IDE, SATA, or SAS-connected flash devices
like the Samsung MCBQE32G5MPP-0VA? I mean, it seems lovely - 32GB, at a
transfer rate of 100MB/s, and
On Thu, Jun 26, 2008 at 9:49 AM, Peter T. Breuer [EMAIL PROTECTED] wrote:
Also sprach Merlin Moncure:
As discussed down thread, software raid still gets benefits of
write-back caching on the raid controller...but there are a couple of
(I wish I knew what write-back caching was!)
hardware
On Thu, Jun 26, 2008 at 12:14 PM, Matthew Wakeling [EMAIL PROTECTED] wrote:
None of these manufacturers rates these drives for massive amounts of
writes. They're sold as suitable for laptop/desktop use, which normally is
not a heavy wear and tear operation like a DB. Once they claim
Also sprach Merlin Moncure:
write back: raid controller can lie to host o/s. when o/s asks
This is not what the linux software raid controller does, then. It
does not queue requests internally at all, nor ack requests that have
not already been acked by the components (modulo the fact that one
On Thu, Jun 26, 2008 at 1:03 AM, Peter T. Breuer [EMAIL PROTECTED] wrote:
Also sprach Merlin Moncure:
write back: raid controller can lie to host o/s. when o/s asks
This is not what the linux software raid controller does, then. It
does not queue requests internally at all, nor ack requests
On Thu, 26 Jun 2008, Peter T. Breuer wrote:
Also sprach Merlin Moncure:
The linux software raid algorithms are highly optimized, and run on a
I can confidently tell you that that's balderdash both as a Linux author
and as a software RAID linux author (check the attributions in the
kernel
Hi List;
Anyone have any experiences to share per setting up a federated
architecture with PostgreSQL ? I wonder if the dblink contrib works
well in a federated scenario, specifically in the setup of the
federated views which equate to a select * from the same table on each
federated
On Thu, Jun 26, 2008 at 4:33 PM, kevin kempter
[EMAIL PROTECTED] wrote:
Anyone have any experiences to share per setting up a federated architecture
with PostgreSQL ? I wonder if the dblink contrib works well in a federated
scenario, specifically in the setup of the federated views which equate
On Thu, Jun 26, 2008 at 5:41 PM, Josh Berkus [EMAIL PROTECTED] wrote:
Not to self-plug, but if you require it, EnterpriseDB includes
Oracle-style database links (SELECT col FROM [EMAIL PROTECTED]) which support
predicate push-down.
Also check out Skytools:
On Thu, 26 Jun 2008, Holger Hoffstaette wrote:
How do large databases treat mass updates? AFAIK both DB2 and Oracle use
MVCC (maybe a different kind?) as well
An intro to the other approaches used by Oracle and DB2 (not MVCC) is at
Jonah,
Hmm, I didn't think the Skype tools could really provide federated
database functionality without a good amount of custom work. Or, am I
mistaken?
Sure, what do you think pl/proxy is for?
--
--Josh
Josh Berkus
PostgreSQL @ Sun
San Francisco
--
Sent via pgsql-performance mailing
On Thu, 26 Jun 2008, Peter T. Breuer wrote:
Double buffering is a killer.
No, it isn't; it's a completely trivial bit of overhead. It only exists
during the time when blocks are queued to write but haven't been written
yet. On any database system, in those cases I/O congestion at the disk
On Thu, Jun 26, 2008 at 6:31 PM, Josh Berkus [EMAIL PROTECTED] wrote:
Sure, what do you think pl/proxy is for?
Well, considering that an application must be written specifically to
make use of it, and for very specific scenarios, I wouldn't consider
it as making PostgreSQL a federated database.
On Wednesday 25 June 2008 11:24:23 Greg Smith wrote:
What I often do is get a hardware RAID controller, just to accelerate disk
writes, but configure it in JBOD mode and use Linux or other software RAID
on that platform.
JBOD + RAIDZ2 FTW ;-)
--
Robert Treat
Build A Brighter LAMP :: Linux
On Thu, Jun 26, 2008 at 10:47 PM, Greg Smith [EMAIL PROTECTED] wrote:
On Thu, 26 Jun 2008, Henrik wrote:
I've seen some concerns about buying database performance hardware from
DELL. Are there at least some of the RAID cards that work well with Linux or
should I stay clear of DELL
33 matches
Mail list logo
