On Fri, Mar 09, 2007 at 04:57:18PM +, Simon Riggs wrote:
> On Fri, 2007-03-09 at 11:47 -0500, Tom Lane wrote:
> > "Simon Riggs" <[EMAIL PROTECTED]> writes:
> > > On Fri, 2007-03-09 at 11:15 -0500, Tom Lane wrote:
> > >> It strikes me that allowing archive_command to be changed on the fly
> > >>
On Mon, Mar 19, 2007 at 06:55:56PM -0700, Jeff Davis wrote:
> On Mon, 2007-03-19 at 21:24 -0400, Tom Lane wrote:
> > Jeff Davis <[EMAIL PROTECTED]> writes:
> > > We can already keep stats for a functional index. Is there a reason we
> > > can't keep stats for a multi-column index?
> >
> > The ques
On Wed, Mar 21, 2007 at 12:37:36PM -0400, Chris Browne wrote:
> 4. A different mechanism would be to add a fifth storage column
> strategy (the present four are PLAIN, EXTENDED, EXTERNAL, MAIN), let's
> say, TOAST.
>
> At present, the 4 values are essentially advisory; columns get TOASTed
> if th
On Mon, Mar 19, 2007 at 12:05:19PM +, Simon Riggs wrote:
> I was unwilling to compromise to have HOT if only one index existed, but
> IMHO allowing HOT with <= 3 indexes is an acceptable compromise for this
> release. (We can always use vertical partitioning techniques to allow
> additional acc
On Sun, Apr 01, 2007 at 12:36:01AM +0200, Peter Eisentraut wrote:
> Tom Lane wrote:
> > I seem to remember that we'd agreed that autovacuum should ignore any
> > globally set statement_timeout, on the grounds that a poorly chosen
> > setting could indefinitely prevent large tables from being vacuum
On Fri, Apr 13, 2007 at 03:02:28PM +0200, Dany DeBontridder wrote:
> On 4/13/07, Heikki Linnakangas <[EMAIL PROTECTED]> wrote:
> >
> >Dany DeBontridder wrote:
> >> I'm working to implement a new feature to pg_dump: the ability to dump
> >> objects like function, indexes...
> >
> >pg_dump already du
On Sun, Apr 15, 2007 at 08:00:23PM -0300, Josh Berkus wrote:
> Now, while each of these students has an assigned mentor, that doesn't
> mean other people shouldn't help. If you're interested in their work,
> please pitch in.
>
> Note that we'll also be using the pgsql-students mailing list for
On Tue, Apr 17, 2007 at 12:51:51PM -0700, Joshua D. Drake wrote:
> Jim C. Nasby wrote:
> >On Sun, Apr 01, 2007 at 12:36:01AM +0200, Peter Eisentraut wrote:
> >>Tom Lane wrote:
> >>>I seem to remember that we'd agreed that autovacuum should ignore any
> >
On Tue, Apr 17, 2007 at 02:28:18PM -0400, Tom Lane wrote:
> I doubt that supporting a single multibyte character would be an
> interesting extension --- if we wanted to do anything at all there, we'd
> just generalize the delimiter to be an arbitrary string. But it would
> certainly slow down COPY
On Wed, Apr 18, 2007 at 09:09:11AM -0400, Greg Smith wrote:
> I'm mostly done with my review of the "Automatic adjustment of
> bgwriter_lru_maxpages" patch. In addition to issues already brought up
> with that code, there are some small things that need to be done to merge
> it with the recent
On Wed, Apr 18, 2007 at 06:39:34PM +1200, Martin Langhoff wrote:
> Keyword expansions are generally bad because SCM tools should track
> _content_ - and keyword expansions _modify_ it to add metadata that is
> somewhat redundant, obtainable in other ways, and should just not be in
> the middle of t
On Thu, Apr 19, 2007 at 10:07:08AM +1200, Martin Langhoff wrote:
> Jim C. Nasby wrote:
> > Then how do you tell what version a file is if it's outside of a
> > checkout?
>
> It's trivial for git to answer that - the file will either be pristine,
> and then we c
Moving to -hackers.
On Fri, May 11, 2007 at 04:37:44PM +0100, Heikki Linnakangas wrote:
> >If you know when the checkpoint ended, and you know how long each of the
> >pieces took, you can reconstruct the other times easily. The way you
> >describe this it is true--that the summary is redundant
On Sun, May 13, 2007 at 07:54:20AM +0100, Heikki Linnakangas wrote:
> Maybe we should improve the stats system so that we can collect events
> with timestamps and durations, but in my experience log files actually
> are the most reliable and universal way to collect real-time performance
> infor
On Tue, May 15, 2007 at 01:18:42PM -0400, Bruce Momjian wrote:
> > In Debian's bug tracking system, when the bug is created (which is done
> > by sending an email to a certain address) it gets a number, and the
> > email is distributed to certain lists. People can then reply to that
> > mail, and
On Tue, May 15, 2007 at 10:25:35AM -0700, Jeff Davis wrote:
> On Tue, 2007-05-15 at 10:42 +0100, Heikki Linnakangas wrote:
> > Luke Lonergan wrote:
> > > 32 buffers = 1MB with 32KB blocksize, which spoils the CPU L2 cache
> > > effect.
> > >
> > > How about using 256/blocksize?
> >
> > Sounds rea
On Tue, May 15, 2007 at 12:42:28PM -0400, Bruce Momjian wrote:
> Joshua D. Drake wrote:
> > > Patch status:
> > >
> > > http://developer.postgresql.org/index.php/Todo:PatchStatus
> >
> > If... this is actually a problem (I leave to other committers and
> > reviewers to comment) then I suggest
On Tue, May 15, 2007 at 10:32:14PM +0200, Magnus Hagander wrote:
> Stefan Kaltenbrunner wrote:
> >> They are not stable. The items should point to the archives, which are
> >> supposedly more stable. (I had already fixed one item in PatchStatus
> >> this morning). Really it would be much nicer t
On Tue, May 15, 2007 at 04:37:28PM +0100, Heikki Linnakangas wrote:
> While testing the buffer ring patch, I noticed that bulk inserts with
> both INSERT and COPY pin and unpin the buffer they insert to for every
> tuple. That means that the usage_count of all those buffers are bumped
> A fix
On Tue, May 15, 2007 at 07:01:39PM -0400, Bruce Momjian wrote:
> > Unless you're really in love with doing that sort of thing it's really
> > good that someone else did it. You're one of a handful of folks that can
> > actually review patches, while there's any number of us that can update
> > a wi
Simon intended to commit this per
http://archives.postgresql.org/pgsql-hackers/2007-03/msg01761.php
(actually, there was a change in what was being done). I suspect this
item isn't valid any longer.
On Tue, May 15, 2007 at 07:30:58PM -0400, Bruce Momjian wrote:
>
> This has been saved for the 8.4
On Wed, May 16, 2007 at 10:46:50AM -0400, Alvaro Herrera wrote:
> > > I am not sure. We will have to investigate more the capabilities of the
> > > bug tracking system we intend to use. In the worst case one could add
> > > the URL for the archived message copy; second worst would be bouncing
> >
On Wed, May 16, 2007 at 08:58:44AM +0100, Dave Page wrote:
> Jim C. Nasby wrote:
> > On Tue, May 15, 2007 at 10:32:14PM +0200, Magnus Hagander wrote:
> >> Stefan Kaltenbrunner wrote:
> >>>> They are not stable. The items should point to the archives, which are
&
On Wed, May 16, 2007 at 12:33:38AM -0300, Marc G. Fournier wrote:
> Someone (you, I think) advocated a '3 weeks and then dump the rest of the
> patches' (not quote as strong of wording, but similar) ... why not split the
> patches list up:
>
> submitted patches, not reviewed
> reviewed patches,
On Wed, May 16, 2007 at 09:43:36AM -0400, Gregory Stark wrote:
>
> I'm looking for corner cases where the concurrent psql patch doesn't handle
> things properly. I'm wondering about multiple result sets but I can't think of
> any cases where I can test them.
>
> If you submit multiple commands at
On Wed, May 16, 2007 at 04:34:56PM +0100, Dave Page wrote:
> >How much visibility do we have into the mhonarc database? We should be
> >able to come up with a simple redirector that would point the old
> >mhonarc URLs to URLs for the new system...
>
> database?
And here I thought the reason we u
On Wed, May 16, 2007 at 07:48:10PM +0200, Magnus Hagander wrote:
> Dave Page wrote:
> >>> I the current URLs represent the month, and the ID of the message as
> >>> it comes out of the mbox I believe. We could probably write a script
> >>> to dump a list of message IDs, directories and mbox positio
On Wed, May 16, 2007 at 09:32:44PM +0100, Richard Huxton wrote:
> Dave Page wrote:
> >Richard Huxton wrote:
> >>Magnus Hagander wrote:
> >>It's been on my list to rewrite the whole archive system for a while
> >>for various reasons. There is quite a bit of crossover with the patch
> >>t
On Thu, May 17, 2007 at 11:02:31PM -0400, Greg Smith wrote:
> On Thu, 17 May 2007, David Fetter wrote:
>
> >Would you be interested in providing this meat? You're uniquely
> >qualified because your shins still smart from all the things you
> >barked them on :)
>
> Unfortunately I'm temporarily o
On Thu, May 17, 2007 at 12:30:45PM -0700, Joshua D. Drake wrote:
> It seems that it may be useful to allow something like:
>
> DROP INDEX NOWAIT.
>
> The idea being, that the terminal will come back, the index will be
> dropped in the background. If it doesn't drop, it rollback like normal
> an
On Fri, May 18, 2007 at 12:33:11AM +0800, Cui Shijun wrote:
> Thank you for your suggestions, I am thinking about "Full page writes
> improvement". It seems not so complicated, just fit for a novice like
> me.
> I'll work on it. :-)
Updated on http://developer.postgresql.org/index.php/Todo:Patc
On Fri, May 18, 2007 at 03:21:00PM +0200, Zdenek Kotala wrote:
> What's about
>
> - full page writes improvement
>
> but I will have time after PGCon.
Added you to the list for that at
http://developer.postgresql.org/index.php/Todo:PatchStatus
--
Jim Nasby [
On Fri, May 18, 2007 at 01:39:56PM -0400, Neil Conway wrote:
> On Fri, 2007-18-05 at 13:29 -0400, Alvaro Herrera wrote:
> > I think what Joshua really wants is an equivalent of this
>
> That's not what his original email asked for, at any rate.
>
> > start:
> > BEGIN;
> > LOCK TABLE foo I
On Sat, May 19, 2007 at 01:41:47PM -0400, Tom Lane wrote:
> > I _could_ make tables that "correspond"
> > to the views and put BEFORE INSERT triggers on them and
> > have the triggers insert into the views (or the equalivent),
> > but then the users would have to use the views for most
> > things a
On Mon, May 21, 2007 at 05:02:29PM +, Karl O. Pinc wrote:
>
> On 05/21/2007 11:23:57 AM, Jim C. Nasby wrote:
>
> >What about adding COPY support to rules? ISTM if you want to copy into
> >a
> >view you probably want to insert into it as well, so why not use the
&g
Just had a rather disturbing event happen on platypus..
[EMAIL
PROTECTED]:07]~/buildfarm/HEAD/pgsql.39276/src/interfaces/ecpg/test/results:271>ll
preproc-variable.*
-rw-r--r-- 1 buildfarm decibel 6328 May 26 23:42 preproc-variable.c
-rw-r--r-- 1 buildfarm decibel 76460670919 May 27
On Fri, Jun 01, 2007 at 01:50:12PM -0400, Bruce Momjian wrote:
> I think the long-term solution is to go to a 2k/8k fragment/block model,
> but that isn't going to happen for 8.3.
There might well have been lessons learned since UFS (anyone know what
ZFS does in this regard?), but I agree that we
On Sat, Jun 02, 2007 at 01:37:19PM +, Tasneem Memon wrote:
> We can make the system ask the user as to what membership degree s/he wants
> to get the values, but we don?t want to make the system interactive, where a
> user gives a membership degree value of his/her choice. These operators are
On Mon, Jun 04, 2007 at 11:04:26AM -0400, Alvaro Herrera wrote:
> The launcher is set up to wake up in autovacuum_naptime seconds at most.
> So if the user configures a ridiculuos time (for example 86400 seconds,
> which I've seen) then the launcher would not detect the postmaster death
Yeah, I've
On Fri, Jun 08, 2007 at 09:49:56AM -0400, Matthew O'Connor wrote:
> Michael Paesold wrote:
> >Matthew T. O'Connor schrieb:
> >>Do we need a configurable autovacuum naptime at all? I know I put it
> >>in the original contrib autovacuum because I had no idea what knobs
> >>might be needed. I can'
On Thu, Jun 07, 2007 at 12:13:09PM -0700, Andrew Hammond wrote:
> On 6/7/07, Jim C. Nasby <[EMAIL PROTECTED]> wrote:
> >On Mon, Jun 04, 2007 at 11:04:26AM -0400, Alvaro Herrera wrote:
> >> The launcher is set up to wake up in autovacuum_naptime seconds at most.
> >
On Tue, Jun 05, 2007 at 05:52:39PM -, Andrew Hammond wrote:
> On Jun 5, 9:19 am, [EMAIL PROTECTED] (Alvaro Herrera) wrote:
> > Zdenek Kotala wrote:
> > > Tom Lane wrote:
> > > >Bruce Momjian <[EMAIL PROTECTED]> writes:
> > > >>Is this a TODO?
> >
> > > >I don't think so; there is no demand from
I'm working with a customer that recently discovered that some code had
generated the following nice query...
SELECT ... WHERE table_id = 92838278! AND ...
So their production server now has several processes that are trying to
compute some absurdly large factorial. There's two issues here:
1) t
On Thu, Jun 07, 2007 at 10:16:25AM -0400, Tom Lane wrote:
> Heikki Linnakangas <[EMAIL PROTECTED]> writes:
> > Thinking about this whole idea a bit more, it occured to me that the
> > current approach to write all, then fsync all is really a historical
> > artifact of the fact that we used to use
On Sun, Jun 10, 2007 at 08:49:24PM +0100, Heikki Linnakangas wrote:
> Jim C. Nasby wrote:
> >On Thu, Jun 07, 2007 at 10:16:25AM -0400, Tom Lane wrote:
> >>Heikki Linnakangas <[EMAIL PROTECTED]> writes:
> >>>Thinking about this whole idea a bit more, it occured t
From
http://developer.postgresql.org/pgdocs/postgres/routine-vacuuming.html :
"Recommended practice for most sites is to schedule a database-wide
VACUUM once a day at a low-usage time of day, supplemented by more
frequent vacuuming of heavily-updated tables if necessary. (Some
installations with e
On Tue, Jul 03, 2007 at 11:31:08AM +0200, Michael Paesold wrote:
> Joshua D. Drake wrote:
> >Alvaro Herrera wrote:
> >>Joshua D. Drake wrote:
> >>>Did we change the default autovac parameters for 8.3 (beyond turning
> >>>it on?) because on any reasonably used database, they are way to
> >>>conser
On Mon, Jul 02, 2007 at 11:19:12PM -0400, Tom Lane wrote:
> "Jim C. Nasby" <[EMAIL PROTECTED]> writes:
> > http://developer.postgresql.org/pgdocs/postgres/routine-vacuuming.html :
>
> Well, with autovac defaulting to ON in 8.3, that's certainly obsolete
>
On Tue, Jul 03, 2007 at 11:49:05AM -0400, Bruce Momjian wrote:
> Tom Lane wrote:
> > Alvaro Herrera <[EMAIL PROTECTED]> writes:
> > > Tom Lane escribi?:
> > >> I rather doubt that. The most likely implementation would involve
> > >> cloning a "template" entry into pg_class.
> >
> > > How about a
On Wed, Jul 04, 2007 at 01:03:20PM +0200, Dawid Kuroczko wrote:
> Hello.
>
> I think it could be a nice idea to put descriptions from
> http://www.postgresql.org/docs/8.2/static/catalogs.html
> into system catalogs itself. I.e., make a bunch of
>
> COMMENT ON COLUMN pg_class.relname
>IS 'Nam
On Mon, Jul 09, 2007 at 07:04:27PM +0100, Gregory Stark wrote:
> "Tom Lane" <[EMAIL PROTECTED]> writes:
>
> > Now, because we surround the pattern with ^...$ anyway, I can't offhand
> > see a use-case for putting $ with its regexp meaning into the pattern.
>
> It's possible to still usefully use
According to http://developer.postgresql.org/index.php/Feature_Matrix,
8.2 has non-blocking CREATE INDEX, which is news to me. Is it correct?
http://developer.postgresql.org/index.php?title=Feature_Matrix&oldid=1734
is the version where that was added (very early in the history of the
page).
--
J
On Fri, Jul 13, 2007 at 01:45:18PM -0700, Joshua D. Drake wrote:
> Jim C. Nasby wrote:
> >According to http://developer.postgresql.org/index.php/Feature_Matrix,
> >8.2 has non-blocking CREATE INDEX, which is news to me. Is it correct?
>
> CREATE INDEX CONCURRENTLY
Well, I gu
Is it really necessary to block reads on a table that is affected by
adding a foreign key constraint? I can see why you wouldn't want UPDATES
or INSERTS on the child table or DELETEs on the parent, but select
should be fine on both tables, no?
--
Jim C. Nasby (aka De
On Wed, Jun 11, 2003 at 03:19:14PM -0400, Tom Lane wrote:
> "Jim C. Nasby" <[EMAIL PROTECTED]> writes:
> > Is it really necessary to block reads on a table that is affected by
> > adding a foreign key constraint?
>
> It's trickier than you seem to think
On Thu, Jun 12, 2003 at 06:23:12PM -0400, Tom Lane wrote:
> "Jim C. Nasby" <[EMAIL PROTECTED]> writes:
> > Is there any ALTER that would require blocking selects?
>
> DROP INDEX, for certain.
Sure, but that's usually trivially fast.
> > Even stuff like
trying to
allocate/write to too much memory. At least then you have some chance of
keeping the system up (obviously you'd need to leave some amount free so
you could login to the box to fix things).
--
Jim C. Nasby (aka Decibel!)[EMAIL PROTECTED]
Member: Triangle Fraterni
ing all the backed-up cron jobs, the
machine ground to a crawl (mmm... system load of 400+ on a dual
PII-375), and X did crash (though I think that's because I tried
switching to a different virtual console), but the machine stayed up and
eventually worked through everything.
--
Jim C. Na
m is
essentially being used as a disk cache (at least for reads)?
--
Jim C. Nasby (aka Decibel!)[EMAIL PROTECTED]
Member: Triangle Fraternity, Sports Car Club of America
Give your computer some brain candy! www.distributed.net Team #1828
Windows: "Where do you want to go to
e cached.
I've recently been bitten by this. On DB2, I could change what
bufferpool the large tables were using and set it fairly small, but
obviously not an option with PGSQL. But, if pgsql could stop caching
from occuring on user-specified queries, large table or index scans,
etc., it wo
things lag for an instant, the platter will have to make another
> rotation before the call comes back to the userland.
If it would help, I have a quad xeon-550 with a 4 drive raid5 and 2
drive mirror (all SCSI, 7200RPM I think) available.
--
Jim C. Nasby (aka Decibel!)[EM
Currently, the FreeBSD ports make the following change when building
python:
--- src/pl/plpython/Makefile.orig Fri Nov 19 20:23:01 2004
+++ src/pl/plpython/MakefileTue Dec 28 23:32:16 2004
@@ -9,7 +9,7 @@
# shared library. Since there is no official way to determine this
# (at least n
On Sun, Oct 15, 2006 at 10:39:49PM +0200, Peter Eisentraut wrote:
> Jim C. Nasby wrote:
> > Currently, the FreeBSD ports make the following change when building
> > python:
> >
> > --- src/pl/plpython/Makefile.orig Fri Nov 19 20:23:01 2004
> > +++ src/pl/plpy
On Sun, Oct 15, 2006 at 06:19:12PM -0400, Tom Lane wrote:
> "Jim C. Nasby" <[EMAIL PROTECTED]> writes:
> > Take a look at the failure output...
>
> > ERROR: could not load library
> > "/home/buildfarm/buildfarm/HEAD/inst/lib/postgresql/plpython.so
Since installing python 2.5, tapir has been failing:
http://pgbuildfarm.org/cgi-bin/show_log.pl?nm=tapir&dt=2006-10-15%2020:20:16
Several of the failures appear to be a simple change in error reporting;
I haven't investigated why import_succeed() failed.
Should python 2.5 work with plpython?
--
AIL PROTECTED]> wrote:
> >
> >On Sat, 2006-10-14 at 11:32 +0530, NikhilS wrote:
> >
> >> On 10/13/06, Jim C. Nasby <[EMAIL PROTECTED]> wrote:
> >
> >
> >> I'm also not sure if this metric is what you actually want
On Tue, Oct 17, 2006 at 04:34:35PM +0300, Marko Kreen wrote:
> >I'm not sure if anyone else needs something like it, but it allows us to
> >transparently encrypt data directly in the tables. Minimum application
> >changes ('select enc_key' at connection) - the main requirement when
> >working on le
On Wed, Oct 18, 2006 at 09:25:01PM +0930, Shane Ambler wrote:
> I haven't noticed any torrent files for postgreSQL releases - maybe we
> can look into setting this up to share the load, particularly around
> release times.
We used to release torrents but stopped because they weren't all that
pop
Yes, well, we english speakers get to deal with the monstrosity that is
'www'. :)
In any case, I believe coalesce is in the standard, and even if it's
not, Oracle is the only database I know of that doesn't use it.
If you're that unhappy with coalesce and ||, you can always create
functions that
Moving to -sql.
On Wed, Oct 18, 2006 at 06:53:46PM +0530, Indira Muthuswamy wrote:
> Hai,
>
> I have encountered a problem with PostgreSQL.I have created a table
> 'tab1' with a column 'a' with serial type.I entered 20 records into the
> table.So the query
> select max(a) from tab1;
> returned 2
On Wed, Oct 18, 2006 at 05:15:13PM -0400, jungmin shin wrote:
> Hello all,
>
> I read a paper, which is Query optimization in the presence of Foreign
> Functions.
> And the paper , there is a paragraph like below.
>
> In order to reduce the number of invocations, caching the results of
> invoca
And PLEASE do not post something to 3 lists; it's a lot of extra traffic
for no reason.
Moving to -hackers.
On Wed, Oct 18, 2006 at 05:15:13PM -0400, jungmin shin wrote:
> Hello all,
>
> I read a paper, which is Query optimization in the presence of Foreign
> Functions.
> And the paper , there
On Thu, Oct 19, 2006 at 04:10:46PM +0530, NikhilS wrote:
> Hi Jim,
>
> On 10/18/06, Jim C. Nasby <[EMAIL PROTECTED]> wrote:
> >
> >Also how many times a relation has been vacuumed (which puts all the
> >other numbers in more perspective... good catch Simon). An
On Thu, Oct 19, 2006 at 11:47:53AM -0400, Tom Lane wrote:
> "Jim C. Nasby" <[EMAIL PROTECTED]> writes:
> > BTW, if we add these counters we'll be up to 7 stats dealing with vacuum
> > and analyze, and NikhilS has a patch we're finalizing that would add 3
&
On Thu, Oct 19, 2006 at 06:32:08PM -0400, Tom Lane wrote:
> So I'm inclined to leave the behavior as-is. The documentation for
> log_statement already says
>
> Note: Statements that generate syntax errors are not logged. Set
> log_min_error_statement to error to log such statements.
On Thu, Oct 19, 2006 at 02:37:34PM -0400, Neil Conway wrote:
> Why does adminpack install functions into pg_catalog? This is
> inconsistent with the rest of the contrib/ packages, not to mention the
> definition of pg_catalog itself (which ought to hold builtin object
> definitions). And as AndrewS
On Fri, Oct 20, 2006 at 03:30:40AM +0300, Tux P wrote:
> Hi .*
>
> Is there any chance to see the quota implementation described in this post
> in any next releases?
>
> http://archives.postgresql.org/pgsql-hackers/2004-07/msg00392.php
Since Jonah hasn't done anything with it he's presumably los
If the decision to vacuum based on autovacuum criteria is good enough
for you then I think you should just focus on getting autovac to do what
you want it to do. Perhaps you just need to decrease the sleep time to a
few seconds, so that autovac will quickly detect when something needs to
be vacuume
On Mon, Oct 23, 2006 at 03:08:03PM -0400, Tom Lane wrote:
> "Jim C. Nasby" <[EMAIL PROTECTED]> writes:
> > The only case I can think of where autovac might not work as well as
> > smartvacuum would be if you had a lot of databases in the cluster, since
> > aut
On Mon, Oct 23, 2006 at 11:39:34PM -0400, Bruce Momjian wrote:
> Query Broadcast Replication
> ---
>
> This involves sending write queries to multiple servers. Read-only
> queries can be sent to a single server because there is no need for all
> servers to process it. Th
On Tue, Oct 24, 2006 at 03:33:03PM -0700, Joshua D. Drake wrote:
> Simon Riggs wrote:
> > On Tue, 2006-10-24 at 15:13 -0700, Joshua D. Drake wrote:
> >
> >> If it were me, I would say that the replication option has to be
> >> specific to PostgreSQL (e.g; cjdbc or synchronous jakarta pooling
> >>
On Wed, Oct 25, 2006 at 08:22:25PM +0930, Shane Ambler wrote:
> Bruce Momjian wrote:
>
> >OK, does that mean we mention EnterpriseDB in the section about Oracle
> >functions? Why not mention MS SQL if they have a better solution? I
> >just don't see where that line can clearly be drawn on what t
On Wed, Oct 25, 2006 at 11:38:11AM +0200, Markus Schiltknecht wrote:
> I can't really get excited about the exclusion of the term
> 'replication', because it's what most people are looking for. It's a
> well known term. Sorry if it sounded that way, but I've not meant to
> avoid that term.
> I
On Wed, Oct 25, 2006 at 09:24:16AM +0530, rajesh boppana wrote:
> i want to implement materialized views in postgresql . to do as i
> want to modify the code in backend but i don't know what r the files i have
> to modify. so please help me by mentioning about the backend code.
If you're g
On Wed, Oct 25, 2006 at 04:42:17PM -0400, Bruce Momjian wrote:
> Dawid Kuroczko wrote:
> > Bruce, I've read Your documentation and I was left a bit with a feeling
> > that it's a bit too generic. It's almost as if it could be about just about
> > any major database, not PostgreSQL specific. I fee
On Wed, Oct 25, 2006 at 08:42:07PM -0400, Bruce Momjian wrote:
> Jim C. Nasby wrote:
> > Something else worth doing though is to have a paragraph explaining why
> > there's no built-in replication. I don't have time to write something
> > right now, but I can do it l
On Thu, Oct 26, 2006 at 03:35:11PM -0400, Jeff Trout wrote:
>
> On Oct 26, 2006, at 3:23 PM, Martijn van Oosterhout wrote:
>
> >On Thu, Oct 26, 2006 at 03:15:00PM -0400, Andrew Dunstan wrote:
> >>Perhaps people who use other platforms could look for these flags
> >>in the
> >>output of
> >> p
On Thu, Oct 26, 2006 at 11:59:57AM -0400, Bruce Momjian wrote:
> Jim C. Nasby wrote:
> > On Wed, Oct 25, 2006 at 08:42:07PM -0400, Bruce Momjian wrote:
> > > Jim C. Nasby wrote:
> > > > Something else worth doing though is to have a paragraph explaining why
> >
On Thu, Oct 26, 2006 at 06:11:59PM -0400, Chris Campbell wrote:
> On Oct 26, 2006, at 17:21, Tom Lane wrote:
>
> >And what was 1171 doing? I really doubt that either of these could
> >have
> >been pg_dump.
>
> I know that process 1120 is a Java client (Hibernate) running an
> UPDATE query, b
On Fri, Oct 27, 2006 at 01:19:25PM -, Greg Sabino Mullane wrote:
> > This is documented clearly on the psql man page, so it is simply not a
> > bug, and changing this would probably break lots of legacy scripts.
>
> In a general sense, perhaps, but in this *particular* case, I don't
> see what
One issue is that I'm not sure think you've got your sugar quite right.
Have you tested with:
(col IS NOT NULL AND 123 IS NOT NULL AND col = 123) OR
(col IS NULL and 123 IS NULL) ?
It's possible that the planner doesn't know about using an index for
DISTINCT; or it might just want an index th
On Sun, Nov 05, 2006 at 09:53:08PM +0100, Martijn van Oosterhout wrote:
> Note that the constructs:
>
> ARRAY['a',"NULL",'c']
>
> and
>
> '{a,"NULL",c}'
>
> are *completely* different. The first is a special array constructor
> and all its parameters are normal SQL expressions, so you can refer
On Tue, Nov 07, 2006 at 11:03:42AM +0100, Martijn van Oosterhout wrote:
> On Mon, Nov 06, 2006 at 09:10:40PM -0500, JEAN-PIERRE PELLETIER wrote:
> > I understand that the planner doesn't use indexes for IS NOT DISTINCT FROM,
> > but it would
> > be good because "is not distinct from" is very usefu
Tapir appears to be failing because make check wants more than 10
connections for testing. What I don't understand is why it's being
limited to 10. initdb -d doesn't help either...
...
selecting default max_connections ... 10
selecting default shared_buffers/max_fsm_pages ... 32MB/204800
creating
On Tue, Dec 12, 2006 at 03:26:32PM -0500, Bruce Momjian wrote:
> Heikki Linnakangas wrote:
> > > The maintain_cluster_order patch is useful by itself, and handles an
> > > existing TODO regarding pulling pages out of WAL in a specified order to
> > > maintain clustering.
> >
> > Pull pages out of
On Fri, Dec 08, 2006 at 11:43:27AM -0500, Tom Lane wrote:
> "Kevin Grittner" <[EMAIL PROTECTED]> writes:
> > "Jim C. Nasby" <[EMAIL PROTECTED]> wrote:
> >> Generally, I try and configure the all* settings so that you'll get 1
> >> cl
On Wed, Dec 13, 2006 at 06:27:38PM +0900, Takayuki Tsunakawa wrote:
> No. BgBufferSync() correctly keeps track of the position to restart
> scanning at. bufid1 is not initialized to 0 every time BgBufferSync()
> is called, because bufid1 is a static local variable. Please see the
> following code.
On Mon, Dec 11, 2006 at 12:24:12AM +0100, Peter Eisentraut wrote:
> Simon Riggs wrote:
> > Well, I'd like a way of making EXPLAIN ANALYZE return something
> > useful within a reasonable amount of time. We can define that as the
> > amount of time that the user considers is their goal for the query.
On Mon, Dec 11, 2006 at 12:08:30PM -0500, Tom Lane wrote:
> "Greg Sabino Mullane" <[EMAIL PROTECTED]> writes:
> > Short version: is it optimal for vacuum to always populate reltuples
> > with live rows + dead rows?
>
> If we didn't do that, it would tend to encourage the use of seqscans on
> table
On Wed, Dec 27, 2006 at 10:54:57PM +, Simon Riggs wrote:
> On Wed, 2006-12-27 at 23:26 +0100, Martijn van Oosterhout wrote:
> > On Wed, Dec 27, 2006 at 09:24:06PM +, Simon Riggs wrote:
> > > On Fri, 2006-12-22 at 13:53 -0500, Bruce Momjian wrote:
> > >
> > > > I assume other kernels have s
1 - 100 of 1353 matches
Mail list logo
