"Larry Rosenman" writes:
> Tom Lane wrote:
>> Looks like we're fairly well covered on freebsd already. Are you
>> willing to consider running some less-popular OS on it?
> What were you thinking?
[ shrug... ] Anything you don't see paired with amd64 on the buildfarm
roster is OK by me ...
Tom Lane wrote:
> "Larry Rosenman" <[EMAIL PROTECTED]> writes:
>> I've got a fast FreeBSD/amd64 server available to run Buildfarm
>> on.
>
>> However, I see we already have a couple of others running it.
>
>> My questions are:
>> 1) do we need another one?
>> 2) if yes, what
Fellow
hacker,I am new comer to postgres development community. Currently, I
am implementing tightly coupled machine classifiers within postgres. The
grammer looks like Train Parameter_list (class1,class2,class3...). I have
two major problems right now.1. Train is a statement an
On Jan 20, 2006, at 10:50 , Christopher Kings-Lynne wrote:
Yes. Representation of the DNA is probably best. But - that's a
lot of
data to use as a key in multiple tables. :-)
No then you have problems with identical twins :)
And, looking forward, clones.
Michael Glaesemann
grzm myrealbox
On Thu, 19 Jan 2006, Jim C. Nasby wrote:
> > Feel free to do whatever with this, it's pretty fast for tables where
> > seeks to validate tuples would hurt, but you do get back dead things...
>
> How'd you then weed out the dead tuples?
I didn't get that far with it. The purpose of this function
Yes. Representation of the DNA is probably best. But - that's a lot of
data to use as a key in multiple tables. :-)
No then you have problems with identical twins :)
Chris
---(end of broadcast)---
TIP 3: Have you checked our extensive FAQ?
"Larry Rosenman" <[EMAIL PROTECTED]> writes:
> I've got a fast FreeBSD/amd64 server available to run Buildfarm on.
> However, I see we already have a couple of others running it.
> My questions are:
> 1) do we need another one?
> 2) if yes, what options need coverage?
Looks l
On Thu, Jan 19, 2006 at 04:54:21PM -0600, Jim C. Nasby wrote:
> You could also do this by doing a filesystem copy of $PG_DATA (with
> postgresql shut down), and then restoring that copy after your test. If
> you used rsync (or something that allowed filesystem snapshots) this
> probably wouldn't be
On Tue, 2006-01-17 at 21:43 +, Simon Riggs wrote:
> On Tue, 2006-01-17 at 09:52 -0500, Tom Lane wrote:
> > I was thinking along the lines of having multiple temp files per hash
> > bucket. If you have a tuple that needs to migrate from bucket M to
> > bucket N, you know that it arrived before
"Jim C. Nasby" <[EMAIL PROTECTED]> writes:
> Basically, numbers talk. If there were convincing numbers for something
> that wasn't a corner-case that showed a marked improvement then there'd
> be much more interest in getting this into the backend in some fashion.
I've got no doubt that there are
Simon Riggs <[EMAIL PROTECTED]> writes:
> This seems to lead to a super-geometric progression in the number of
> files required,
But we double the number of batches at each step, so there are going to
be at most 20 or so levels, and that's only assuming a *horridly* wrong
initial guess by the plan
On Thu, Jan 19, 2006 at 02:50:39PM -0800, Jeremy Drake wrote:
> On Thu, 19 Jan 2006, Jim C. Nasby wrote:
>
> > Do you still have that patch that folks could look at? ISTM that this
> > technique would be rather dependant on your actual workload, and as such
> > could result in a big win for certai
You could also do this by doing a filesystem copy of $PG_DATA (with
postgresql shut down), and then restoring that copy after your test. If
you used rsync (or something that allowed filesystem snapshots) this
probably wouldn't be very painful.
On Thu, Jan 19, 2006 at 03:54:33PM -0500, uwcssa wrote
Thomas Hallgren wrote:
> Hi,
> I'd like to get a general understanding of what kind of structures
> PostgreSQL puts in shared memory and how they are managed. I'd like some
> hints on where to start looking. Source, docs, prior discussions,
> anything is considered helpful.
Have you looked on t
Hi,
I'd like to get a general understanding of what kind of structures
PostgreSQL puts in shared memory and how they are managed. I'd like some
hints on where to start looking. Source, docs, prior discussions,
anything is considered helpful.
TIA,
Thomas Hallgren
---(
Bruce Momjian writes:
> Because random returns a double, I think it is very possible that we
> could return 1 due to rounding,
Not unless your machine has a "double" type with less than 32 bits of
precision, which seems pretty unlikely. It'd be sufficient to do
/* result 0.0 <= x < 1.0
On Wed, 2006-01-18 at 20:13 -0500, Tom Lane wrote:
> Come to think of it, the idea also seems to map nicely into bitmap index
> scans: the index will directly hand back a list of potential pages to
> look at, but they are all marked "lossy" because the index doesn't know
> exactly which tuple(s) o
src/backend/utils/adt/float.c:
/*
* drandom - returns a random number
*/
Datum
drandom(PG_FUNCTION_ARGS)
{
float8 result;
/* result 0.0-1.0 */
result = ((double) random()) / ((double) MAX_RANDOM_VALUE);
PG_RETURN_FLOAT8(result);
}
On Thu, Jan 19, 2006 at 05:03:20PM -0500, Tom Lane wrote:
> I'm still bothered by the likelihood that there are cache-flush bugs in
> code paths that are not exercised by the regression tests. The
> CLOBBER_CACHE patch is far too slow to consider enabling on any regular
> basis, but it seems that
On Thu, 2006-01-19 at 14:25 -0500, uwcssa wrote:
> I have a simple question here, not sure if i should posted here but
> if you have the quick answer, it helps a lot
>
> i have a table that is already "vacuum"ed. for some reason i want
> to un-vacuum it instead of dropping the table and recreate
On Thu, Jan 19, 2006 at 03:54:33PM -0500, uwcssa wrote:
> I want to do this for repeating some experiment results, not for
> tuning the db (pretty much like using an old machine to find
> performance difference for an algorithm). so if i have a way
> of knowing which tables are storing the statis
Fellow hacker,
I am new comer to postgres development community. Currently, I am
implementing tightly coupled machine classifiers within postgres. The
grammer looks like Train Parameter_list (class1,class2,class3...). I have
two major problems right now.
1. Train is a statement and it is sup
Where are we on this? Rajesh, I think we are waiting for more
information from you.
---
R, Rajesh (STSD) wrote:
>
> That was very much situation specific.
> But the bottomline is the default test does not include in the
>
On Thu, Jan 19, 2006 at 11:46:29PM +0200, Hannu Krosing wrote:
> ??hel kenal p??eval, K, 2006-01-18 kell 22:35, kirjutas uwcssa:
> > I am testing the performance of postgresql on a set of workloads.
> > However,
> > the output significantly affects the performance evaluation. Is there
> > a way
>
Greetings,
I've got a fast FreeBSD/amd64 server available to run Buildfarm on.
However, I see we already have a couple of others running it.
My questions are:
1) do we need another one?
2) if yes, what options need coverage?
Thanks,
LER
--
Larry Rosenman
Database
On Thu, 19 Jan 2006, Jim C. Nasby wrote:
> Do you still have that patch that folks could look at? ISTM that this
> technique would be rather dependant on your actual workload, and as such
> could result in a big win for certain types of queries.
It is not a patch, per se. It is a c language fun
Andrew - Supernews wrote:
> src/backend/utils/adt/float.c:
>
> /*
> *drandom - returns a random number
> */
> Datum
> drandom(PG_FUNCTION_ARGS)
> {
> float8 result;
>
> /* result 0.0-1.0 */
> result = ((double) random()) / ((double) MAX_RANDOM_VALU
I want to do this for repeating some experiment results, not for
tuning the db (pretty much like using an old machine to find
performance difference for an algorithm). so if i have a way
of knowing which tables are storing the statistics, i guess i can
delete all from that table to archieve this.
"Jim C. Nasby" <[EMAIL PROTECTED]> writes:
> How would this affect changing the type of a column?
It doesn't, because we drop and rebuild indexes completely during ALTER
COLUMN TYPE.
regards, tom lane
---(end of broadcast)--
Michael Fuhr <[EMAIL PROTECTED]> writes:
> On Thu, Jan 19, 2006 at 03:54:33PM -0500, uwcssa wrote:
>> I want to do this for repeating some experiment results, not for
>> tuning the db (pretty much like using an old machine to find
>> performance difference for an algorithm). so if i have a way
>>
I've completed a round of stress testing the system for vulnerabilities
to unexpected cache flush events (relcache, catcache, or typcache
entries disappearing while in use). I'm pleased to report that the 8.1
branch now passes all available regression tests (main, contrib, pl)
with CLOBBER_CACHE_A
Ühel kenal päeval, K, 2006-01-18 kell 22:35, kirjutas uwcssa:
> I am testing the performance of postgresql on a set of workloads.
> However,
> the output significantly affects the performance evaluation. Is there
> a way
> to by-pass all output of select statements so the timing reflects only
> th
On Thu, Jan 19, 2006 at 10:09:26AM -0800, Josh Berkus wrote:
> Martjin,
>
> >In any of these either misspellings, changes of names, ownership or
> >even structure over time render the obvious useless as keys. There are
> >techniques for detecting and reducing duplication but the point is that
> >f
Peter Eisentraut <[EMAIL PROTECTED]> writes:
> Tom Lane wrote:
>> There is another possible answer, and it's something I've been
>> meaning to bring up for awhile. Is there a good reason why
>> postmaster is a symlink to postgres, rather than a hard link?
> I don't know of one. Something I have
On Thu, Jan 19, 2006 at 02:46:11AM -0500, Tom Lane wrote:
> Greg Stark <[EMAIL PROTECTED]> writes:
> > Tom Lane <[EMAIL PROTECTED]> writes:
> >> But you couldn't make any meaningful changes in the definition of an
> >> index, such as changing its column set, operator classes, partial-index
> >> pre
Joshua D. Drake wrote:
Michael Paesold wrote:
You don't user pl/perl, do you -- i.e. I guess you read the latest
release notes and the thread here before that?
Yes I did. I didn't know that the person was running plPerl. I have
verified that they are. We are now going to check if upgrading to
On Thu, Jan 19, 2006 at 01:48:18PM -0600, Jim C. Nasby wrote:
> On Thu, Jan 19, 2006 at 02:01:14PM -0500, [EMAIL PROTECTED] wrote:
> > On Thu, Jan 19, 2006 at 10:11:51AM -0800, Josh Berkus wrote:
> > > > So ISTM it's much easier to just use surrogate keys and be
> > > >done with it. Only deviate wh
On Thu, Jan 19, 2006 at 10:35:30AM -0800, David Scott wrote:
> Tom Lane wrote:
>
> >What sort of problems are you dealing with exactly? There has been
> >some discussion of changes that would improve certain scenarios. For
> >instance it might be plausible to do joins using index information and
On Thu, Jan 19, 2006 at 10:19:01AM -0800, Josh Berkus wrote:
> One of the other most valuable targets for index-only access is the
> "many-to-many join table" whose primary key consists of two (or more)
> foreign keys to two (or more) other tables. It's actually not necessary
> to check visibil
On Thu, Jan 19, 2006 at 11:22:24AM -0800, Dann Corbit wrote:
> > > In any of these either misspellings, changes of names, ownership or
> > > even structure over time render the obvious useless as keys. There
> are
> > > techniques for detecting and reducing duplication but the point is
> that
> > >
On Thu, Jan 19, 2006 at 02:01:14PM -0500, [EMAIL PROTECTED] wrote:
> On Thu, Jan 19, 2006 at 10:11:51AM -0800, Josh Berkus wrote:
> > > So ISTM it's much easier to just use surrogate keys and be
> > >done with it. Only deviate when you have a good reason to do so.
> > "The lazy man's guide to SQL d
Ühel kenal päeval, N, 2006-01-19 kell 14:25, kirjutas uwcssa:
> I have a simple question here, not sure if i should posted here but
> if you have the quick answer, it helps a lot
>
> i have a table that is already "vacuum"ed. for some reason i want
> to un-vacuum it instead of dropping the table
On 1/19/06, uwcssa <[EMAIL PROTECTED]> wrote:
> I have a simple question here, not sure if i should posted here but
> if you have the quick answer, it helps a lot
>
> i have a table that is already "vacuum"ed. for some reason i want
> to un-vacuum it instead of dropping the table and recreate the
On Thu, Jan 19, 2006 at 02:25:15PM -0500, uwcssa wrote:
> i have a table that is already "vacuum"ed. for some reason i want
> to un-vacuum it instead of dropping the table and recreate the table
> and indexes on it. is there a existing command to do so?
What effect do you want this un-vacuum to
I have a simple question here, not sure if i should posted here but
if you have the quick answer, it helps a lot
i have a table that is already "vacuum"ed. for some reason i want
to un-vacuum it instead of dropping the table and recreate the table
and indexes on it. is there a existing command t
> -Original Message-
> From: [EMAIL PROTECTED] [mailto:pgsql-hackers-
> [EMAIL PROTECTED] On Behalf Of Josh Berkus
> Sent: Thursday, January 19, 2006 10:09 AM
> To: Martijn van Oosterhout
> Cc: pgsql-hackers@postgresql.org
> Subject: Re: [HACKERS] Surrogate keys (Was: enums)
>
> Martjin,
Hi there,
we did a 8.1 compatible version of tsearchd, available from
http://www.sai.msu.su/~megera/oddmuse/index.cgi/Tsearch2
tsearchd is our old experiment with inverted index. It's
fully compatible with tsearch2, actually it's tsearch2+several functions
and daemon. Very brief documentation
On Thu, Jan 19, 2006 at 10:11:51AM -0800, Josh Berkus wrote:
> > So ISTM it's much easier to just use surrogate keys and be
> >done with it. Only deviate when you have a good reason to do so.
> "The lazy man's guide to SQL database design", but Jim Nasby.
> ;-)
Hehe... I was thinking the same thin
Tom Lane wrote:
What sort of problems are you dealing with exactly? There has been
some discussion of changes that would improve certain scenarios. For
instance it might be plausible to do joins using index information and
only go back to the heap for entries that appear to pass the join test.
Thanks for all the help and thought to our problem.
Jonah H. Harris wrote:
David has stated that the index to heap visibility check is slowing
him down, so what are the possible options:
- Visibility in indexes (-hackers archives cover the pros/cons)
- True organized heaps
- Block level ind
Michael Paesold wrote:
Joshua D. Drake wrote:
Tom Lane wrote:
What's the database's locale? This could be the same problem fixed in
8.0.6, if the locale has weird ideas about what string equality means.
lc_collate | C
lc_ctype | C
You don't user
Jonah,
David has stated that the index to heap visibility check is slowing him
down, so what are the possible options:
- Visibility in indexes (-hackers archives cover the pros/cons)
- True organized heaps
- Block level index (Tom/Simon's earlier discussion)
also
- Frozen relations
This l
Jim,
> So ISTM it's much easier to just use surrogate keys and be
done with it. Only deviate when you have a good reason to do so.
"The lazy man's guide to SQL database design", but Jim Nasby.
;-)
--Josh
---(end of broadcast)---
TIP 3: Have y
Martjin,
In any of these either misspellings, changes of names, ownership or
even structure over time render the obvious useless as keys. There are
techniques for detecting and reducing duplication but the point is that
for any of these duplicates *can* be valid data.
Please point me out where
Tom Lane wrote:
> find_my_exec is not misbehaving: it's designed to expand symlinks,
> and would in fact be pretty useless if it did not.
I don't want to contest that in certain cases this is required but I can
easily come up with scenarios (which perhaps no PostgreSQL user has
encountered yet)
On Thu, Jan 19, 2006 at 09:37:12AM -0500, Pollard, Mike wrote:
> The point? Surrogate keys and natural keys are two tools in the
> database arsenal. Just as it is unwise to use a hammer to drive a screw
> just because you don't believe in screwdrivers, it is unwise to just off
> hand discard eith
On 19 Jan 2006 11:25:21 -0500, Greg Stark <[EMAIL PROTECTED]> wrote:
Well it seems there were lots of facts posted. Yes you can avoid headachescaused by these issues, but we're not really talking about the headaches.Several were mentioned; some of which could generally be avoided by good tuning.
We
Peter Eisentraut <[EMAIL PROTECTED]> writes:
> Earlier, CreateOptsFile was called with argv, now it's passed the result of
> find_my_exec instead. I'm not sure whether that change was wrong to begin
> with or whether find_my_exec is mishaving (it should return something
> containing "postmaster
"Jonah H. Harris" <[EMAIL PROTECTED]> writes:
> As an Oracle internals person myself, I don't see how making a comparison
> between the specifics of Oracle's MVCC to PostgreSQL's MVCC is relevant to
> this discussion.
>
> As does *MOST* other commercial databases, Oracle's storage manager perfor
Joshua D. Drake wrote:
Tom Lane wrote:
What's the database's locale? This could be the same problem fixed in
8.0.6, if the locale has weird ideas about what string equality means.
lc_collate | C
lc_ctype | C
You don't user pl/perl, do you -- i.e.
[EMAIL PROTECTED] writes:
> On Thu, Jan 19, 2006 at 09:37:12AM -0500, Pollard, Mike wrote:
>> Martijn van Oosterhout wrote:
>> > Please provides natural keys for any of the following:
>> > - A Person
>> > - A phone call: (from,to,date,time,duration) is not enough
>> > - A physical address
>> > - A
lc_collate | C
lc_ctype | C
OK, scratch that theory. Don't suppose you can create a reproducible
test case ;-)
That may be a bit tough... What really struck me is that the
duplication only occurs in this set of 100 tables and the
duplication is alw
"Joshua D. Drake" <[EMAIL PROTECTED]> writes:
> Tom Lane wrote:
>> What's the database's locale? This could be the same problem fixed in
>> 8.0.6, if the locale has weird ideas about what string equality means.
> lc_collate | C
> lc_ctype | C
OK, scrat
Tom Lane wrote:
"Joshua D. Drake" <[EMAIL PROTECTED]> writes:
Odd problem with unique indexes:
What's the database's locale? This could be the same problem fixed in
8.0.6, if the locale has weird ideas about what string equality means.
lc_collate | C
lc_ctype
On Thu, Jan 19, 2006 at 01:56:51AM -0500, Greg Stark wrote:
> Tom Lane <[EMAIL PROTECTED]> writes:
>
> > Christopher Kings-Lynne <[EMAIL PROTECTED]> writes:
> > >> Oracle does, but you pay in other ways. Instead of keeping dead tuples
> > >> in the main heap, they shuffle them off to an 'undo log'
kevin brintnall <[EMAIL PROTECTED]> writes:
> GRANT SELECT (col1, col2, col3) ON table1, table2 TO grantee;
> Is it reasonable to restrict this to a single relation, and throw an error
> if multiple relations are specified?
The SQL spec doesn't actually allow multiple things after GRANT ... O
On Thu, Jan 19, 2006 at 09:37:12AM -0500, Pollard, Mike wrote:
> Martijn van Oosterhout wrote:
> > Please provides natural keys for any of the following:
> > - A Person
> > - A phone call: (from,to,date,time,duration) is not enough
> > - A physical address
> > - A phone line: (phone numbers arn't u
Martijn van Oosterhout wrote:
> Please provides natural keys for any of the following:
>
> - A Person
> - A phone call: (from,to,date,time,duration) is not enough
> - A physical address
> - A phone line: (phone numbers arn't unique over time)
> - An internet account: (usernames not unique over ti
Am Donnerstag, 19. Januar 2006 09:50 schrieb kevin brintnall:
> GRANT SELECT (col1, col2, col3) ON table1, table2 TO grantee;
>
> Is it reasonable to restrict this to a single relation, and throw an error
> if multiple relations are specified?
Yes
--
Peter Eisentraut
http://developer.postgre
As an Oracle internals person myself, I don't see how making a comparison between the specifics of Oracle's MVCC to PostgreSQL's MVCC is relevant to this discussion.As does *MOST* other commercial databases, Oracle's storage manager performs an update-in-place whereas PostgreSQL's (for the most par
On Wed, Jan 18, 2006 at 05:27:29PM -0500, Tom Lane wrote:
> Right, the deadlock risk is exactly the reason you need some secret
> sauce or other. Btree's page-level lock ensures that two insertions of
> conflicting keys can't overlap (even if they ultimately get stored on
> different pages). That
Bruce Momjian wrote:
OK, thanks. Next question --- are the installed file locations the same
for a MinGW install and a pginstaller install? I don't think
pginstaller does a MinGW install because it doesn't have the build
environment in the tarball.
However, the big difference seems to be t
Since 8.0, postmaster.opts has been containing .../bin/postgres even though
the postmaster was started. This was evidently broken by some
Windows-related reshuffling.
Earlier, CreateOptsFile was called with argv, now it's passed the result of
find_my_exec instead. I'm not sure whether that ch
On Thu, Jan 19, 2006 at 12:50:52AM -0800, David Fetter wrote:
> On Thu, Jan 19, 2006 at 12:06:41AM -0500, Tom Lane wrote:
> No, that's not the big problem. The big problem is that it's very
> likely illegal for you to use it for anything unless you happen to be
> the Social Security Administration
On Thu, Jan 19, 2006 at 12:06:41AM -0500, Tom Lane wrote:
> Michael Glaesemann <[EMAIL PROTECTED]> writes:
> > As far as I can tell, the only difference between your position,
> > Dann, and Date and Darwen's, is that you think no natural key is
> > immutable.
>
> D&D's examples of "natural" keys a
Fellow hackers,
I'm curious about the best way to handle something like this:
GRANT SELECT (col1, col2, col3) ON table1, table2 TO grantee;
Is it reasonable to restrict this to a single relation, and throw an error
if multiple relations are specified? That would require the preceding
grant
Em Qui, 2006-01-19 às 09:54 +0900, Michael Glaesemann escreveu:
> On Jan 19, 2006, at 9:31 , Leandro Guimarães Faria Corcete Dutra wrote:
>
> If these are things
> you're interested in (and it certainly appears you are), why not
> contribute?
'Cause unfortunately am not a hacker...
On Thu, Jan 19, 2006 at 02:46:11AM -0500, Tom Lane wrote:
> The concerns that I find more interesting are changes in the underlying
> objects. We don't have an ALTER OPERATOR CLASS, much less an ALTER
> ACCESS METHOD, but it's certainly theoretically possible to change the
> definition of a suppor
78 matches
Mail list logo
