>
> have you considered importing to a temporary 'holding' table with
> copy, then doing 'big' sql statements on it to check constraints, etc?
>
Yes I considered it, but the problem is the data is very tight related
between different tables and is important to keep the import order of each
entit
On Tue, 12 Aug 2008, Ron Mayer wrote:
Really old software (notably 2.4 linux kernels) didn't send
cache synchronizing commands for SCSI nor either ATA; but
it seems well thought through in the 2.6 kernels as described
in the Linux kernel documentation.
http://www.mjmwired.net/kernel/Documentatio
Scott Marlowe wrote:
I can attest to the 2.4 kernel not being able to guarantee fsync on
IDE drives.
Sure. But note that it won't for SCSI either; since AFAICT the write
barrier support was implemented at the same time for both.
--
Sent via pgsql-performance mailing list (pgsql-performance@
I'm not an expert on which and where -- its been a while since I was exposed
to the issue. From what I've read in a few places over time (
storagereview.com, linux and windows patches or knowledge base articles), it
happens from time to time. Drives usually get firmware updates quickly.
Drivers /
On Tue, 12 Aug 2008, Ron Mayer wrote:
Scott Carey wrote:
Some SATA drives were known to not flush their cache when told to.
Can you name one? The ATA commands seem pretty clear on the matter,
and ISTM most of the reports of these issues came from before
Linux had write-barrier support.
I c
On Tue, Aug 12, 2008 at 6:23 PM, Scott Carey <[EMAIL PROTECTED]> wrote:
> Some SATA drives were known to not flush their cache when told to.
> Some file systems don't know about this (UFS, older linux kernels, etc).
>
> So yes, if your OS / File System / Controller card combo properly sends the
> w
Scott Carey wrote:
Some SATA drives were known to not flush their cache when told to.
Can you name one? The ATA commands seem pretty clear on the matter,
and ISTM most of the reports of these issues came from before
Linux had write-barrier support.
I've yet to hear of a drive with the problem
Some SATA drives were known to not flush their cache when told to.
Some file systems don't know about this (UFS, older linux kernels, etc).
So yes, if your OS / File System / Controller card combo properly sends the
write cache flush command, and the drive is not a flawed one, all is well.
Most sh
Hello All,
Ran into a re-occuring performance problem with some report queries again
today. In a nutshell, we have filters on either multiple joined tables, or
multiple columns on a single table that are highly correlated. So, the
estimates come out grossly incorrect (the planner has no way to k
Greg Smith wrote:
some write cache in the SATA disks...Since all non-battery backed caches
need to get turned off for reliable database use, you might want to
double-check that on the controller that's driving the SATA disks.
Is this really true?
Doesn't the ATA "FLUSH CACHE" command (say,
On Tue, Aug 12, 2008 at 1:40 PM, Henrik <[EMAIL PROTECTED]> wrote:
> Hi again all,
>
> Just wanted to give you an update.
>
> Talked to Dell tech support and they recommended using write-through(!)
> caching in RAID10 configuration. Well, it didn't work and got even worse
> performance.
Someone at
Hi again all,
Just wanted to give you an update.
Talked to Dell tech support and they recommended using write-
through(!) caching in RAID10 configuration. Well, it didn't work and
got even worse performance.
Anyone have an estimated what a RAID10 on 4 15k SAS disks should
generate in rand
Bill Moran wrote:
In response to Steve Atkins <[EMAIL PROTECTED]>:
On Aug 12, 2008, at 8:21 AM, Bill Moran wrote:
In response to Moritz Onken <[EMAIL PROTECTED]>:
Am 12.08.2008 um 17:04 schrieb Bill Moran:
In response to Moritz Onken <[EMAIL PROTECTED]>:
On Tue, Aug 12, 2008 at 4:17 AM, Sabin Coanda
<[EMAIL PROTECTED]> wrote:
>> long running transactions can be evil. is there a reason why this has
>> to run in a single transaction?
>
> This single transaction is used to import new information in a database. I
> need it because the database cannot b
Bill Moran wrote:
We chose UUID as PK because there is still some information in an
integer key.
You can see if a user has registered before someone else
(user1.id <
user2.id)
or you can see how many new users registered in a specific period
of
time
(compare the id of the newest user to the
In response to Steve Atkins <[EMAIL PROTECTED]>:
>
> On Aug 12, 2008, at 8:21 AM, Bill Moran wrote:
>
> > In response to Moritz Onken <[EMAIL PROTECTED]>:
> >
> >>
> >> Am 12.08.2008 um 17:04 schrieb Bill Moran:
> >>
> >>> In response to Moritz Onken <[EMAIL PROTECTED]>:
> >>>
> We chose UU
On Aug 12, 2008, at 8:21 AM, Bill Moran wrote:
In response to Moritz Onken <[EMAIL PROTECTED]>:
Am 12.08.2008 um 17:04 schrieb Bill Moran:
In response to Moritz Onken <[EMAIL PROTECTED]>:
We chose UUID as PK because there is still some information in an
integer key.
You can see if a user
Am 12.08.2008 um 17:21 schrieb Bill Moran:
In response to Moritz Onken <[EMAIL PROTECTED]>:
Am 12.08.2008 um 17:04 schrieb Bill Moran:
In response to Moritz Onken <[EMAIL PROTECTED]>:
We chose UUID as PK because there is still some information in an
integer key.
You can see if a user has
In response to Moritz Onken <[EMAIL PROTECTED]>:
>
> Am 12.08.2008 um 17:04 schrieb Bill Moran:
>
> > In response to Moritz Onken <[EMAIL PROTECTED]>:
> >
> >> We chose UUID as PK because there is still some information in an
> >> integer key.
> >> You can see if a user has registered before som
Tx to all.
I reach the same reflection on partitionning the data to those tables.
And postgresql is giving very good tools for that with the rules features.
I got the SAS server for immediate fix.
But I'm looking for buying a machine that will handle my needs for more
long time.
Regarding p
Am 12.08.2008 um 17:04 schrieb Bill Moran:
In response to Moritz Onken <[EMAIL PROTECTED]>:
We chose UUID as PK because there is still some information in an
integer key.
You can see if a user has registered before someone else (user1.id <
user2.id)
or you can see how many new users registere
In response to Moritz Onken <[EMAIL PROTECTED]>:
> We chose UUID as PK because there is still some information in an
> integer key.
> You can see if a user has registered before someone else (user1.id <
> user2.id)
> or you can see how many new users registered in a specific period of
> time
We chose UUID as PK because there is still some information in an
integer key.
You can see if a user has registered before someone else (user1.id <
user2.id)
or you can see how many new users registered in a specific period of
time
(compare the id of the newest user to the id a week ago). Thi
On Tue, Aug 12, 2008 at 9:46 AM, Gregory Stark <[EMAIL PROTECTED]> wrote:
> "Mark Mielke" <[EMAIL PROTECTED]> writes:
>
>>- Increased keyspace. Even if keyspace allocation is performed, an int4
>> only
>> has 32-bit of keyspace to allocate. The IPv4 address space is already over
>> 85%
>> all
Gregory Stark wrote:
"Mark Mielke" <[EMAIL PROTECTED]> writes:
- Increased keyspace. Even if keyspace allocation is performed, an int4 only
has 32-bit of keyspace to allocate. The IPv4 address space is already over 85%
allocated as an example of how this can happen. 128-bits has a LOT mor
Hi!
We use normal sequences to generate id's across multiple nodes. We
use the "increment" parameter for the sequence and we specify each
node to increment its sequence with for example 10 and the the first
node to start the sequence at 1 and the second at 2 and so on. In that
way you ge
"Mark Mielke" <[EMAIL PROTECTED]> writes:
>- Increased keyspace. Even if keyspace allocation is performed, an int4
> only
> has 32-bit of keyspace to allocate. The IPv4 address space is already over 85%
> allocated as an example of how this can happen. 128-bits has a LOT more
> keyspace than
Bill Moran wrote:
The main reason to use UUID instead of sequences is if you want to be able to
generate unique values across multiple systems. So, for example, if you want
to be able to send these userids to another system which is taking
registrations from lots of places. Of course that only wo
In response to Gregory Stark <[EMAIL PROTECTED]>:
> "Mario Weilguni" <[EMAIL PROTECTED]> writes:
>
> > UUID is already a surrogate key not a natural key, in no aspect better than
> > a
> > numeric key, just taking a lot more space.
> >
> > So why not use int4/int8?
>
> The main reason to use UU
"Mario Weilguni" <[EMAIL PROTECTED]> writes:
> UUID is already a surrogate key not a natural key, in no aspect better than a
> numeric key, just taking a lot more space.
>
> So why not use int4/int8?
The main reason to use UUID instead of sequences is if you want to be able to
generate unique val
You guys totally rock!
I guess, bottom line, we should take that extra day to convert our PK and FK
to a numerical value, using BIG INT to be on the save side. (Even though
Wikipedia's UserID uses just an integer as data type)
To Gregory: Thank you for you valuable statement.
"But the real questi
Valentin Bogdanov schrieb:
--- On Mon, 11/8/08, Gregory Stark <[EMAIL PROTECTED]> wrote:
From: Gregory Stark <[EMAIL PROTECTED]>
Subject: Re: [PERFORM] Using PK value as a String
To: "Jay" <[EMAIL PROTECTED]>
Cc: pgsql-performance@postgresql.org
Date: Monday, 11 August, 2008, 10:30 AM
"Jay"
> long running transactions can be evil. is there a reason why this has
> to run in a single transaction?
This single transaction is used to import new information in a database. I
need it because the database cannot be disconected from the users, and the
whole new data has to be consistently. T
33 matches
Mail list logo
