On Tue, 19 Sep 2006, Alvaro Herrera wrote:
> Jeremy Drake wrote:
>
> > I have found the same thing with the type "timestamp without time zone".
> > The verbosity of type names seems rather extreme.
>
> Then use simply "timestamptz" (with TZ) or "timestamp" (without).
Didn't know about these, lear
Jeremy Drake wrote:
> I have found the same thing with the type "timestamp without time zone".
> The verbosity of type names seems rather extreme.
Then use simply "timestamptz" (with TZ) or "timestamp" (without).
--
Alvaro Herrerahttp://www.CommandPrompt.com/
Pos
On Tue, Sep 19, 2006 at 11:21:51PM -0400, Alvaro Herrera wrote:
> [EMAIL PROTECTED] wrote:
> > On Tue, Sep 19, 2006 at 08:20:13AM -0500, Jim C. Nasby wrote:
> > > On Mon, Sep 18, 2006 at 07:45:07PM -0400, [EMAIL PROTECTED] wrote:
> > > > I would not use a 100% random number generator for a UUID val
Praveen Kumar N wrote:
> Hi,
> can anybody explain me what is the difference between system cache
> and buffer cache?
>
> I found that keywords in PostgreSql FAQ
> http://www.postgresql.org/docs/faqs.FAQ_DEV.html#item2.1
Another important cache is the "relation cache", relcache for short,
[resending this to the list, was silently dropped this afternoon?]
-- Forwarded message --
From: Merlin Moncure <[EMAIL PROTECTED]>
Date: Sep 19, 2006 11:57 PM
Subject: docs for advisory locks
To: pgsql-patches@postgresql.org
ok, here is the promised docs for the advisory locks.
[EMAIL PROTECTED] wrote:
> On Tue, Sep 19, 2006 at 08:20:13AM -0500, Jim C. Nasby wrote:
> > On Mon, Sep 18, 2006 at 07:45:07PM -0400, [EMAIL PROTECTED] wrote:
> > > I would not use a 100% random number generator for a UUID value as was
> > > suggested. I prefer inserting the MAC address and the ti
On Tue, Sep 19, 2006 at 10:02:40PM -, Andrew - Supernews wrote:
> On 2006-09-19, [EMAIL PROTECTED] <[EMAIL PROTECTED]> wrote:
> > Different UUID forms can be unique within their domain. As long as I
> > control the MAC address assignment for all of my units, my MAC address
> > can be guaranteed
Magnus Hagander wrote:
> if I look into my cvs repository directory, it shows only gram.y,v, with
> gram.c,v in Attic - which seems to make sense. Must be my client that's
> gone crazy. In fact, mmy output ends up as:
>
> Index: src\backend\parser/gram.c
>
On 2006-09-19, [EMAIL PROTECTED] <[EMAIL PROTECTED]> wrote:
> Different UUID forms can be unique within their domain. As long as I
> control the MAC address assignment for all of my units, my MAC address
> can be guaranteed to be unique across space and time,
You do not know (and can never know) t
On Tue, Sep 19, 2006 at 10:11:39AM -0400, Andrew Dunstan wrote:
> [EMAIL PROTECTED] wrote:
> >>As others have mentioned, using MAC address doesn't remove the
> >>possibility of a collision.
> >It does, as I control the MAC address. I can choose not to overwrite it.
> >I can choose to ensure that an
Tom Lane wrote:
Mark Wong <[EMAIL PROTECTED]> writes:
Curious, I'm still seeing the same behavior. Maybe I'll take another
snapshot from CVS.
Hm, maybe I need to try a bit harder here. Does the "not registered"
error happen immediately/reliably for you, or do you need to run the
test awhile?
Bruce Momjian wrote:
Tom Lane wrote:
We've cleared all the must-fix-before-beta issues I mentioned on Sunday.
AFAICS we're good to tag and wrap ...
I think we are ready. Marc will do the stamping outlined in
tools//RELEASE_CHANGES.
Just noting that RPMS will likely be a week out.
Joshua D
The larger version is only hidden from everyone :) http://people.planetpostgresql.org/mha/uploads/photo/conf/conference_group.jpg
[]'s- Walter
Ühel kenal päeval, T, 2006-09-19 kell 12:29, kirjutas Andrew Sullivan:
> On Mon, Sep 18, 2006 at 06:00:22PM -0300, Walter Cruz wrote:
> > Hi all. I don't know if here is the best place, but in:
> > http://conference.postgresql.org/Catalog there's no link to the slides of
> > the talks.
> >
> > I t
Tom Lane wrote:
> We've cleared all the must-fix-before-beta issues I mentioned on Sunday.
> AFAICS we're good to tag and wrap ...
I think we are ready. Marc will do the stamping outlined in
tools//RELEASE_CHANGES.
--
Bruce Momjian [EMAIL PROTECTED]
EnterpriseDBhttp://www.enterprisedb
Stefan Kaltenbrunner <[EMAIL PROTECTED]> writes:
> ok - the planner switches to a different plan at about 2.5GB of
> effective_cache_size resulting in the following [ much better ] plan:
OK, so it sounds like it'd be a good idea to try to pro-rate
effective_cache_size among all the tables in the q
Alvaro Herrera wrote:
Tom Lane wrote:
Zdenek Kotala <[EMAIL PROTECTED]> writes:
I little bit enhanced overview catalog tables. I added two new columns.
First one is OID of catalog table and second one contains attributes
which determine if the table is bootstrap, with oid and global.
Why is t
No, too late.
---
Simon Riggs wrote:
>
> Way past feature freeze, but this small change allows a powerful new
> feature utilising the Restartable Recovery capability. Very useful for
> very large database backups...
>
> I
Jim C. Nasby wrote:
> On Tue, Sep 19, 2006 at 09:37:39AM -0400, Bruce Momjian wrote:
> > Jim C. Nasby wrote:
> > > On Mon, Sep 18, 2006 at 06:47:02PM -0400, Bruce Momjian wrote:
> > > > > Both this and pg_prepared_statements are very useful for pooled
> > > > > connection setups."
> > > > >
> > >
Tom Lane wrote:
> Gregory Stark <[EMAIL PROTECTED]> writes:
> > Frankly the whole phantom commandid thing sounds more complicated. You
> > *still*
> > need a local state data structure that *still* has to spill to disk and now
> > it's much harder to characterize how large it will grow since it de
Heikki Linnakangas <[EMAIL PROTECTED]> writes:
> Tom Lane kirjoitti:
>> I'm also concerned about loss of debug traceability if these fields
>> disappear entirely from disk --- it's been handy more than once to be
>> able to tell where in a complex transaction something happened.
> Sure. We'll just
Tom Lane wrote:
> Stefan Kaltenbrunner <[EMAIL PROTECTED]> writes:
>> Tom Lane wrote:
>>> I'm not sure what we could do about the concurrent-sessions issue, but
>>> we could make some sort of attack on the query complexity issue by
>>> pro-rating the effective_cache_size among all the tables used b
Tom Lane kirjoitti:
I'm also concerned about loss of debug traceability if these fields
disappear entirely from disk --- it's been handy more than once to be
able to tell where in a complex transaction something happened.
Sure. We'll just have to try to compensate that with debug messages
e
Heikki Linnakangas <[EMAIL PROTECTED]> writes:
> As I tried to say in the first post, I believe we can actually get away
> without an entry in local memory in typical scenarios, including bulk
> data loads.
I didn't find that argument very credible, particularly not the part
that assumes we know
I wrote:
> ... I think maybe
> something is applying an UPDATE to the row and losing the new value
> at that point. Are any of the FKs non-default actions (ON ... SET NULL
> or some such that would try to alter data instead of just erroring)?
I've been able to reproduce a problem that may or may
Tom Lane kirjoitti:
Gregory Stark <[EMAIL PROTECTED]> writes:
Frankly the whole phantom commandid thing sounds more complicated.
You *still*
need a local state data structure that *still* has to spill to disk
and now
it's much harder to characterize how large it will grow since it
depends on
We've cleared all the must-fix-before-beta issues I mentioned on Sunday.
AFAICS we're good to tag and wrap ...
regards, tom lane
---(end of broadcast)---
TIP 1: if posting/reading through Usenet, please send an appropriate
On Tue, Sep 19, 2006 at 06:52:59PM +0200, Lukas Kahwe Smith wrote:
> Thinking a head (and maybe too far then we really need to at this
> point): So how will this work once they become "official". I assume
> Bruce's todo list would then link to the wiki and the editing would
> become more conserv
Gregory Stark <[EMAIL PROTECTED]> writes:
> Well there's a reason we support commandids up to 4 billion. One of the common
> use cases of bulk loading data in a series of individual inserts would cause
> such a structure to spill to disk. As would ISAM style programming that steps
> through a large
Tom Lane <[EMAIL PROTECTED]> writes:
> Gregory Stark <[EMAIL PROTECTED]> writes:
>> Frankly the whole phantom commandid thing sounds more complicated. You
>> *still*
>> need a local state data structure that *still* has to spill to disk and now
>> it's much harder to characterize how large it wil
Martijn van Oosterhout wrote:
On Mon, Sep 18, 2006 at 03:49:29PM +0200, Lukas Kahwe Smith wrote:
I agree pretty much. However I disagree that a wiki is not useful to
summarize discussion from the mailinglist. All that it needs is people
that are humble and do not push their own agendas. If nece
Tom Lane napsal(a):
Zdenek Kotala <[EMAIL PROTECTED]> writes:
I little bit enhanced overview catalog tables. I added two new columns.
First one is OID of catalog table and second one contains attributes
which determine if the table is bootstrap, with oid and global.
Why is this a good idea?
On 9/19/06, Tom Lane <[EMAIL PROTECTED]> wrote:
"Merlin Moncure" <[EMAIL PROTECTED]> writes:
> there are two things going on here: first, i think we are confusing
> the concepts of lockmode and waitmode, and secondly since in most
> other places wait locks are default with an optional nowait cla
Gregory Stark <[EMAIL PROTECTED]> writes:
> Frankly the whole phantom commandid thing sounds more complicated. You *still*
> need a local state data structure that *still* has to spill to disk and now
> it's much harder to characterize how large it will grow since it depends on
> arbitrary combinat
"Merlin Moncure" <[EMAIL PROTECTED]> writes:
> there are two things going on here: first, i think we are confusing
> the concepts of lockmode and waitmode, and secondly since in most
> other places wait locks are default with an optional nowait clause,
> how about make advisory locks follow a simi
On Mon, Sep 18, 2006 at 06:00:22PM -0300, Walter Cruz wrote:
> Hi all. I don't know if here is the best place, but in:
> http://conference.postgresql.org/Catalog there's no link to the slides of
> the talks.
>
> I think that would be nice the slides there :)
Yes.
They are badly overdue. We had
Tom Lane <[EMAIL PROTECTED]> writes:
> Heikki Linnakangas <[EMAIL PROTECTED]> writes:
>> Saving 4 bytes per tuple with the phantom cid is nice, but saving 8
>> bytes (assuming we get rid of xvac in the future, or overlay it with
>> xmin for example) is even better.
>
> xvac is not going away, s
On 9/19/06, Merlin Moncure <[EMAIL PROTECTED]> wrote:
On 9/17/06, Tom Lane <[EMAIL PROTECTED]> wrote:
> We have three possible choices for this: do nothing, install a
> bug-compatible, allegedly-clean-room implementation in contrib:
> http://archives.postgresql.org/pgsql-patches/2006-09/msg00077.
"Merlin Moncure" <[EMAIL PROTECTED]> writes:
> two questions: do we need both a shared and unshared variant of
> advisory_unlock (im guessing no)?
Yes, because it's possible to hold both shared and exclusive lock
concurrently, so you have to say which you're releasing.
> also, are we exposing the
Heikki Linnakangas <[EMAIL PROTECTED]> writes:
> Simon Riggs wrote:
>> +
>> + if (startupAfterRecovery)
>> + ereport(ERROR,
>> + (errmsg("recovery ends normally with startup_after_recovery=false")));
>> +
> I find this part of the patch a bit ugly. Isn't there a better way to
> exit than throwing
Heikki Linnakangas <[EMAIL PROTECTED]> writes:
> Saving 4 bytes per tuple with the phantom cid is nice, but saving 8
> bytes (assuming we get rid of xvac in the future, or overlay it with
> xmin for example) is even better.
xvac is not going away, so that argument is unconvincing, and I don't
be
On 9/17/06, Tom Lane <[EMAIL PROTECTED]> wrote:
We have three possible choices for this: do nothing, install a
bug-compatible, allegedly-clean-room implementation in contrib:
http://archives.postgresql.org/pgsql-patches/2006-09/msg00077.php
or put a hopefully-cleaner design into core, eg per my s
Simon Riggs wrote:
+
+ if (startupAfterRecovery)
+ ereport(ERROR,
+ (errmsg("recovery ends normally with startup_after_recovery=false")));
+
I find this part of the patch a bit ugly. Isn't there a better way to
exit than throwing an error that's not really an error?
--
Heikki Linnakangas
Ent
Tom Lane wrote:
Heikki Linnakangas <[EMAIL PROTECTED]> writes:
I'm thinking of removing cmin and cmax, and keeping that information in
backend-private memory instead.
I don't believe you can remove *both*. What's been discussed is
removing one of them, by letting the field represent a
Heikki Linnakangas <[EMAIL PROTECTED]> writes:
> I'm thinking of removing cmin and cmax, and keeping that information in
> backend-private memory instead.
I don't believe you can remove *both*. What's been discussed is
removing one of them, by letting the field represent a lookup key for an
in-m
Praveen Kumar N wrote:
Buffer cache is implemented using bufferpool right(I mean in the main
memory).
Yes. It's in shared memory, size is controlled by the shared_buffers
configuration parameter.
how about system cache? Can we control the size of system cache?
It's in backend-private memo
On Tue, Sep 19, 2006 at 09:51:23AM -0400, [EMAIL PROTECTED] wrote:
> On Tue, Sep 19, 2006 at 08:20:13AM -0500, Jim C. Nasby wrote:
> > On Mon, Sep 18, 2006 at 07:45:07PM -0400, [EMAIL PROTECTED] wrote:
> > > I would not use a 100% random number generator for a UUID value as was
> > > suggested. I p
[-patches trimmed from list]
[EMAIL PROTECTED] wrote:
As others have mentioned, using MAC address doesn't remove the
possibility of a collision.
It does, as I control the MAC address. I can choose not to overwrite it.
I can choose to ensure that any cases where it is overwritten, it is
o
Way past feature freeze, but this small change allows a powerful new
feature utilising the Restartable Recovery capability. Very useful for
very large database backups...
Includes full documentation.
Perhaps a bit rushed, but inclusion in 8.2 would be great. (Ouch, don't
shout back, read the pa
On Mon, 2006-09-18 at 17:46 +0200, Matteo Beccati wrote:
> Tom Lane ha scritto:
> > Matteo Beccati <[EMAIL PROTECTED]> writes:
> >> I cannot see anything bad by using something like that:
> >> if (histogram is large/representative enough)
> >
> > Well, the question is exactly what is "large enough
On Tue, Sep 19, 2006 at 03:35:55PM +0200, Gevik Babakhani wrote:
> > As others have mentioned, using MAC address doesn't remove the
> > possibility of a collision.
> >
> > Maybe a good compromise that would allow a generator function to go into
> > the backend would be to combine the current time
On Tue, Sep 19, 2006 at 09:37:39AM -0400, Bruce Momjian wrote:
> Jim C. Nasby wrote:
> > On Mon, Sep 18, 2006 at 06:47:02PM -0400, Bruce Momjian wrote:
> > > > Both this and pg_prepared_statements are very useful for pooled
> > > > connection setups."
> > > >
> > > > Should read "Both of these are
On Tue, Sep 19, 2006 at 08:20:13AM -0500, Jim C. Nasby wrote:
> On Mon, Sep 18, 2006 at 07:45:07PM -0400, [EMAIL PROTECTED] wrote:
> > I would not use a 100% random number generator for a UUID value as was
> > suggested. I prefer inserting the MAC address and the time, to at
> > least allow me to c
Buffer cache is implemented using bufferpool right(I mean in the main
memory).how about system cache? Can we control the size of system cache?
On Tue, 19 Sep 2006, Heikki Linnakangas wrote:
System cache is a per-row cache of system catalog tables. It's used to speed
up lookup of things like
Praveen Kumar N wrote:
Hi,
can anybody explain me what is the difference between system cache
and buffer cache?
I found that keywords in PostgreSql FAQ
http://www.postgresql.org/docs/faqs.FAQ_DEV.html#item2.1
System cache is a per-row cache of system catalog tables. It's used to
speed
Jim C. Nasby wrote:
> On Mon, Sep 18, 2006 at 06:47:02PM -0400, Bruce Momjian wrote:
> > > Both this and pg_prepared_statements are very useful for pooled
> > > connection setups."
> > >
> > > Should read "Both of these are very useful..."
> >
> > I don't think I can't change that because they ar
> As others have mentioned, using MAC address doesn't remove the
> possibility of a collision.
>
> Maybe a good compromise that would allow a generator function to go into
> the backend would be to combine the current time with a random number.
> That will ensure that you won't get a dupe, so long
We currently use 4 int32s to store xmin, xmax, cmin, cmax and xvac on
every heap tuple. That's a lot of overhead, especially on tables with
narrow rows. Reduction in header size would give us considerable space
and I/O savings.
I'm thinking of removing cmin and cmax, and keeping that informati
Whoops, I hadn't read this far when I sent the last message on the other
thread.
Gevik Babakhani wrote:
3. Make a small utility that goes through a patch, finds the new OIDs
and changes them back to a value specified by the committer(s).
This is effectively what I ended up suggesting in the
Andrew Dunstan wrote:
You misunderstood me. I meant he wanted to make use of such a facility,
not that he wanted to build it.
Yeah, I had enough things on my plate just getting enums to work :)
By all means float ideas on this - the problem seems to me to be
ensuring that reservations are tim
On Mon, Sep 18, 2006 at 07:45:07PM -0400, [EMAIL PROTECTED] wrote:
> I would not use a 100% random number generator for a UUID value as was
> suggested. I prefer inserting the MAC address and the time, to at
> least allow me to control if a collision is possible. This is not easy
> to do using a fe
On Tue, Sep 19, 2006 at 01:10:48AM +0200, Albert Cervera Areny wrote:
> Hi,
> I've decided to start hacking on PostgreSQL, and I've looked at the
> easier jobs in the TODO list. I'm interested in implementing:
>
> % Add a GUC variable to control the tablespace for temporary objects and so
On Mon, Sep 18, 2006 at 06:47:02PM -0400, Bruce Momjian wrote:
> > Both this and pg_prepared_statements are very useful for pooled
> > connection setups."
> >
> > Should read "Both of these are very useful..."
>
> I don't think I can't change that because they are two separate bullet
> items.
E
Hi,
can anybody explain me what is the difference between system cache
and buffer cache?
I found that keywords in PostgreSql FAQ
http://www.postgresql.org/docs/faqs.FAQ_DEV.html#item2.1
thanks in advance.
Regards,
--
N Praveen Kumar
Imagination is more important than knowledge...
On Tue, 19 Sep 2006, Heikki Linnakangas wrote:
> Jie Zhang wrote:
> > Hi Heikki and all,
> >
> > Please find the latest bitmap index patch in the attachment. This patch is
> > generated against the postgresql cvs head.
> >
>
> Thanks.
>
> The handling of stream and hash bitmaps looks pretty compli
Jie Zhang wrote:
Hi Heikki and all,
Please find the latest bitmap index patch in the attachment. This patch is
generated against the postgresql cvs head.
Thanks.
The handling of stream and hash bitmaps looks pretty complicated to me.
All the bitmap-related nodes have logic to handle both
On Sat, Sep 16, 2006 at 04:19:48PM -0400, Tom Lane wrote:
> "Magnus Hagander" <[EMAIL PROTECTED]> writes:
> > Here goes. Tested only on win32 so far, but works there. No docs yet
> > either - need to know if it goes in first ;)
> I've applied this along with some extra work to get it to show GMT
>
Hi,
I've decided to start hacking on PostgreSQL, and I've looked at the
easier jobs in the TODO list. I'm interested in implementing:
% Add a GUC variable to control the tablespace for temporary objects and sort
files. It could start with a random tablespace from a supplied list and cycl
68 matches
Mail list logo
