Rod Taylor <[EMAIL PROTECTED]> writes:
> On Tue, 2005-04-26 at 23:22 -0400, Tom Lane wrote:
>> You tell us ;-). You've got the test case, attach to it with a debugger
>> and find out what it's doing.
> I wasn't entirely sure how to "catch it in action" so I just used CTRL+C
> to interrupt the pg_
Joshua D. Drake wrote:
>
> >
> > Do companies want to write for Blue Hat PostgreSQL and Suza PostgreSQL
> > because that might be what happens if we don't stay organized? In fact,
> > it might have be happening already.
>
> Well that depends... If the companies are writing for Pervasive
> Post
Do companies want to write for Blue Hat PostgreSQL and Suza PostgreSQL
because that might be what happens if we don't stay organized? In fact,
it might have be happening already.
Well that depends... If the companies are writing for Pervasive
PostgreSQL I don't think they would have a problem wi
> > If we did not define
> > it that way, I think your example would have to error out --- how
> > would you choose which INSTEAD rule wins?
>
> The documentation says that they evaluate in alphabetical order by
> name. So I would expect that the first one to have its WHERE statement
> evaluate
Joshua D. Drake wrote:
> > However, there was a lot of coordination that happened with Fujitsu that
> > I don't see happening with the current companies involved. Companies
> > are already duplicating work that is also done by community members or
> > by other companies.
>
> That is bound to happ
And finally, we have a few companies working on features that they
eventually want merged back into the PostgreSQL codebase. That is a
very tricky process and usually goes badly unless the company seeks
community involvement from the start, including user interface,
implementation, and coding stan
However, there was a lot of coordination that happened with Fujitsu that
I don't see happening with the current companies involved. Companies
are already duplicating work that is also done by community members or
by other companies.
That is bound to happen no matter what. Look at plJava and plJ. S
I am very excited to see companies involved in PostgreSQL development.
It gives us funding for developers and features that is new for us. We
had Fujitsu funding some features for 8.0 and that really helped us.
However, there was a lot of coordination that happened with Fujitsu that
I don't see
Christopher Kings-Lynne wrote:
What's the point of keeping such backend development discussion separate
from the -hackers list? It's always been a mistake in the past...
Yeah, it struck me as a bad idea as well.
-Neil
---(end of broadcast)---
TIP 9:
Christopher Kings-Lynne wrote:
> > There is a fairly lengthy discussion going on right now on the bizgres
> > mailing list about this topic, if your interested in helping out you
> > might want to join that list.
>
> What's the point of keeping such backend development discussion separate
> from
There is a fairly lengthy discussion going on right now on the bizgres
mailing list about this topic, if your interested in helping out you
might want to join that list.
What's the point of keeping such backend development discussion separate
from the -hackers list? It's always been a mistake in
On Tue, 2005-04-26 at 23:22 -0400, Tom Lane wrote:
> Rod Taylor <[EMAIL PROTECTED]> writes:
> > I eventually clued in and made a TOC and removed all of the Slony items,
> > but I'm still curious to know what exactly pg_restore had been doing for
> > the last hour or so.
>
> You tell us ;-). You'v
Jim,
So I interpret that simply proposing work and doing it are all the requirements needed.
Thank you.
Regards,
--
Juan Jose Costello Levien
E-Mail: [EMAIL PROTECTED]
Web: http://jcostello.ath.cxOn 4/27/05, Jim C. Nasby <[EMAIL PROTECTED]
> wrote:See http://www.postgresql.org/docs/fa
On Wed, 2005-04-27 at 20:14 -0400, Tom Lane wrote:
> Rod Taylor <[EMAIL PROTECTED]> writes:
> > What happens if for reasons of broken tape, disk, etc. you lose some of
> > your WAL logs which happens to correspond to the middle of the snapshot
> > backup?
>
> You're screwed ... just like if you lo
See http://www.postgresql.org/docs/faqs.FAQ_DEV.html; esp. items
1.1-1.18.
On Wed, Apr 27, 2005 at 08:35:10PM -0300, Juan Jose Costello Levien wrote:
> Hello,
>
> My name is Juan, and I am interested in being a PostgreSQL Developer. I
> would like to contribute with items in the TODO list. I am
Rod Taylor <[EMAIL PROTECTED]> writes:
> What happens if for reasons of broken tape, disk, etc. you lose some of
> your WAL logs which happens to correspond to the middle of the snapshot
> backup?
You're screwed ... just like if you lost part of the snapshot itself.
If you're really lucky the mis
Hello,
My name is Juan, and I am interested in being a PostgreSQL Developer. I
would like to contribute with items in the TODO list. I am new to the
list, and would like to know if you have reservations or beliefs
applicated to the members of the developer community, so if I can enter
to it or I c
Found another interesting thing while testing this. I got a core dump
from the Assert in GetMultiXactIdMembers, complaining that it was being
asked about a MultiXactId >= nextMXact. Sure enough, there was a
multixact on disk, left over from a previous core-dumped test, that was
larger than the ne
What happens if for reasons of broken tape, disk, etc. you lose some of
your WAL logs which happens to correspond to the middle of the snapshot
backup?
The equivalent would be to:
1) Start the snapshot backup (tar)
2) Stop logging usable WAL logs (say a tape jammed or disk is corrupted)
3) Snapsh
On K, 2005-04-27 at 15:40 -0700, Josh Berkus wrote:
> Hannu,
>
> > > There is a fairly lengthy discussion going on right now on the bizgres
> > > mailing list about this topic, if your interested in helping out you
> > > might want to join that list.
> >
> > Wow! there is a BizGres mailinglist !?
Hannu,
> > There is a fairly lengthy discussion going on right now on the bizgres
> > mailing list about this topic, if your interested in helping out you
> > might want to join that list.
>
> Wow! there is a BizGres mailinglist !?
>
> And this is where the table-partitioning discussion is!
>
> Wh
On T, 2005-04-26 at 16:52 -0400, Robert Treat wrote:
> There is a fairly lengthy discussion going on right now on the bizgres
> mailing list about this topic, if your interested in helping out you
> might want to join that list.
Wow! there is a BizGres mailinglist !?
And this is where the table-
On Wed, Apr 27, 2005 at 05:51:47PM -0400, Tom Lane wrote:
> Suppose that we redo the LOCKTAGs per previous discussion (which I would
> like to do anyway), so that it is possible to define an lmgr lock on a
> particular tuple.
Hm. If you want I can give you the part of the patch that dealt with
c
Alvaro Herrera <[EMAIL PROTECTED]> writes:
> On Wed, Apr 27, 2005 at 11:19:34AM -0400, Tom Lane wrote:
>> Another issue that we may need to think about is that there is no
>> protection against starvation: a would-be acquirer of a row lock
>> could wait forever, because there isn't any mechanism pr
On Wed, Apr 27, 2005 at 11:19:34AM -0400, Tom Lane wrote:
> 1. If several transactions are holding shared lock on a row, and one
> of them wants to actually modify the row (or upgrade its lock to
> exclusive), it must wait for the others to end but can then do so.
> (I think the patch does this pr
Tom Lane wrote:
> Bruce Momjian writes:
> > Tom Lane wrote:
> >> Well, that's just a matter of choosing good (ie short) names for the
> >> backslash commands. I was trying to be clear rather than proposing
> >> names I would actually want to use ;-). Any suggestions?
>
> > Well, if we allowed O
Bruce Momjian writes:
> Tom Lane wrote:
>> Well, that's just a matter of choosing good (ie short) names for the
>> backslash commands. I was trying to be clear rather than proposing
>> names I would actually want to use ;-). Any suggestions?
> Well, if we allowed ON_ERROR_ROLLBACK to work in no
"Dave Held" <[EMAIL PROTECTED]> writes:
> > Actually, it's more to characterize how large of a sample
> > we need. For example, if we sample 0.005 of disk pages, and
> > get an estimate, and then sample another 0.005 of disk pages
> > and get an estimate which is not even close to the first
> >
Tom Lane wrote:
> Andrew Dunstan <[EMAIL PROTECTED]> writes:
> >>> \begin_ignore_error
> >>> DROP TABLE foo;
> >>> \end_ignore_error
>
> > I meant it's a lot to type ;-)
>
> Well, that's just a matter of choosing good (ie short) names for the
> backslash commands. I was trying to be clear rather
> -Original Message-
> From: Josh Berkus [mailto:[EMAIL PROTECTED]
> Sent: Wednesday, April 27, 2005 10:25 AM
> To: Andrew Dunstan
> Cc: Mischa Sandberg; pgsql-perform; pgsql-hackers@postgresql.org
> Subject: Re: [HACKERS] [PERFORM] Bad n_distinct estimation; hacks
> suggested?
>
> [...]
>
Mischa,
> >Perhaps I can save you some time (yes, I have a degree in Math). If I
> >understand correctly, you're trying extrapolate from the correlation
> >between a tiny sample and a larger sample. Introducing the tiny sample
> >into any decision can only produce a less accurate result than just
> -Original Message-
> From: Greg Stark [mailto:[EMAIL PROTECTED]
> Sent: Wednesday, April 27, 2005 1:00 AM
> To: Tom Lane
> Cc: Rod Taylor; Greg Stark; pgsql-hackers@postgresql.org;
> Gurmeet Manku
> Subject: Re: [HACKERS] [PERFORM] Bad n_distinct estimation; hacks
> suggested?
>
> Tom L
I've been reviewing Alvaro's patch for shared row locks, and come across
some corner cases that may need discussion. Does anyone disagree with
the following statements?
1. If several transactions are holding shared lock on a row, and one
of them wants to actually modify the row (or upgrade its lo
When I'm doing a restore and go to start the postmaster it starts
listing off warnings as a result of the pid file being in place. Not a
big deal, but it might be suggested that the tar or cpio process exclude
the postmaster.pid.
--
---(end of broadcast)-
[2005-04-26 23:00] Tom Lane said:
| Brent Verner <[EMAIL PROTECTED]> writes:
| > | I also wonder what happens when
| > | the client and server disagree on the meaning of a filter name.
|
| > How this is any different than saying "...when the client and
| > server disagree on the meaning of a Pro
> -Original Message-
> From: Gurmeet Manku [mailto:[EMAIL PROTECTED]
> Sent: Tuesday, April 26, 2005 5:01 PM
> To: Simon Riggs
> Cc: Tom Lane; josh@agliodbs.com; Greg Stark; Marko Ristola;
> pgsql-perform; pgsql-hackers@postgresql.org; Utkarsh Srivastava;
> [EMAIL PROTECTED]
> Subject: Re:
On Tue, 2005-04-26 at 10:28, Tom Lane wrote:
> "Greg Sabino Mullane" <[EMAIL PROTECTED]> writes:
> > To reiterate my opinion, I think the behavior should be the same
> > for interactive and non-interactive sessions. Not only will it
> > prevent nasty surprises, but unless we make a third 'setting',
There is a fairly lengthy discussion going on right now on the bizgres
mailing list about this topic, if your interested in helping out you
might want to join that list.
Robert Treat
On Tue, 2005-04-26 at 05:43, [EMAIL PROTECTED] wrote:
> Ok!
> The Links your posted are great and i guessing it w
On Tue, 2005-04-26 at 19:03 -0400, Greg Stark wrote:
> This one looks *really* good.
>
> http://www.aladdin.cs.cmu.edu/papers/pdfs/y2001/dist_sampl.pdf
>
> It does require a single full table scan
Ack.. Not by default please.
I have a few large append-only tables (vacuum isn't necessary) whi
Mischa Sandberg wrote:
Perhaps I can save you some time (yes, I have a degree in Math). If I
understand correctly, you're trying extrapolate from the correlation
between a tiny sample and a larger sample. Introducing the tiny sample
into any decision can only produce a less accurate result than
Hi everybody!
Perhaps the following papers are relevant to the discussion here
(their contact authors have been cc'd):
1. The following proposes effective algorithms for using block-level
sampling for n_distinct estimation:
"Effective use of block-level sampling in statistics estimat
hi,
I'm writing an application in C that basically converts binary data into
something meaningful. My first attempt was to parse the binary and insert
directly to the database in one step. But this proved to be very slow. So I
decided to go with a two step process. The first step is to pars
On Sat, 2005-04-23 at 15:04 -0700, Ron Mayer wrote:
> Bruce Momjian wrote:
> > See this TODO: * Allow data to be pulled directly from indexes
> > I think this is the direction we should be heading because it has more
> > general usefulness.
>
> I think read-only tables would have a few different
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
> I'm finding it hard to visualize a non-interactive script making
> any good use of such a setting. Without a way to test whether
> you got an error or not, it would amount to an "ignore errors
> within transactions" mode, which seems a pretty bad
On Tue, 2005-04-26 at 15:00 -0700, Gurmeet Manku wrote:
> 2. In a single scan, it is possible to estimate n_distinct by using
> a very simple algorithm:
>
> "Distinct sampling for highly-accurate answers to distinct value
> queries and event reports" by Gibbons, VLDB 2001.
>
> http://ww
45 matches
Mail list logo
