> > Will 9.1 partitions allow to reference partitioned tables in foreign keys?
>
> For now, you can do something like this:
>
> http://people.planetpostgresql.org/dfetter/index.php?/archives/51-
Partitioning-Is-Such-Sweet-Sorrow.html
>
> Cheers,
> David.
>
Already did ;) But workable plain ref
On Wed, Mar 17, 2010 at 11:42 PM, Bruce Momjian wrote:
> Bruce Momjian wrote:
>> Simon Riggs wrote:
>> > On Sat, 2010-03-13 at 11:26 -0800, Josh Berkus wrote:
>> > > > The list has been reduced greatly in the past week. What about HS/SR
>> > > > open items?
>> > >
>> > > I'd like to see vacuum_de
Bruce Momjian wrote:
> Simon Riggs wrote:
> > On Sat, 2010-03-13 at 11:26 -0800, Josh Berkus wrote:
> > > > The list has been reduced greatly in the past week. What about HS/SR
> > > > open items?
> > >
> > > I'd like to see vacuum_defer_cleanup_age added to the "Archive" section
> > > of postgre
Bruce Momjian wrote:
> Takahiro Itagaki wrote:
> > Since 9.0 has GetPlatformEncoding() for the purpose, we could simplify
> > db_encoding_strdup() with the function. Like this:
>
> OK, I don't have any Win32 people testing this patch so if we want this
> fixed for 9.0 someone is going to have t
Simon Riggs wrote:
> On Sat, 2010-03-13 at 11:26 -0800, Josh Berkus wrote:
> > > The list has been reduced greatly in the past week. What about HS/SR
> > > open items?
> >
> > I'd like to see vacuum_defer_cleanup_age added to the "Archive" section
> > of postgresql.conf,
>
> Not all parameters a
Tom Lane wrote:
> Well, the current ordering is definitely historical rather than
> designed, but I'm hesitant to do more than minor tweaking. Even if we
> think/hope it won't break applications, people are probably used to
> seeing a particular ordering.
>
> I'm not necessarily dead set against
On Wed, 2010-03-17 at 14:09 -0700, Jeff Davis wrote:
> I've been thinking for a while that we could store the visibility
> information in a structure separate from the heap -- sort of like the
> visibility map, but per-tuple and authoritative rather than a per-page
> hint.
A lot of people have be
http://uriel.edu.mx/lN6qt08X2v.html
_
IM on the go with Messenger on your phone
http://go.microsoft.com/?linkid=9712960
On Wed, Mar 17, 2010 at 05:47:49PM -0400, Tom Lane wrote:
> "Kevin Grittner" writes:
> > Tom Lane wrote:
> >> The current column ordering can be rationalized to some extent as
> >>
> >> 1. identity info (user id, db id, application name)
> >> 2. current query info
> >> 3. session info (backend s
"Kevin Grittner" writes:
> Tom Lane wrote:
>> The current column ordering can be rationalized to some extent as
>>
>> 1. identity info (user id, db id, application name)
>> 2. current query info
>> 3. session info (backend start time, client addr/port)
> OK. I guess that trumps my idea, altho
Tom Lane wrote:
> The current column ordering can be rationalized to some extent as
>
> 1. identity info (user id, db id, application name)
> 2. current query info
> 3. session info (backend start time, client addr/port)
OK. I guess that trumps my idea, although it would su
On Wed, 2010-03-17 at 17:20 -0400, Tom Lane wrote:
> Jeff Davis writes:
> > There are all kinds of challenges there, but it might be worth thinking
> > about. Visibility information is highly compressible, and requires
> > constant maintenance (updates, deletes, freezing, etc.). It also might
> >
Bruce Momjian wrote:
> Kevin Grittner wrote:
>> It would scan better, to my mind, if we moved backend_start ahead
>> of xact_start.
>
> Yes, that is another idea that would work, though Tom's idea that
> the query start should be near the query makes sense.
Well, in an ideal world, I would pu
On Mon, 2010-03-15 at 18:20 +0900, Fujii Masao wrote:
> On Sat, Mar 13, 2010 at 12:28 PM, Bruce Momjian wrote:
> > Where are we in getting to beta1? I know people are looking to me for
> > 9.0 release notes and I will have them done in about a week, but what
> > about open issues? I don't see ma
"Kevin Grittner" writes:
> It would scan better, to my mind, if we moved backend_start ahead of
> xact_start.
The current column ordering can be rationalized to some extent as
1. identity info (user id, db id, application name)
2. current query info
3. session info (backe
Kevin Grittner wrote:
> Bruce Momjian wrote:
>
> > xact_start | timestamp with time zone |
> > query_start | timestamp with time zone |
> > backend_start| timestamp with time zone |
>
> > Should we move query_start?
>
> It would scan better, to my mind, if we moved backend_
Jeff Davis writes:
> There are all kinds of challenges there, but it might be worth thinking
> about. Visibility information is highly compressible, and requires
> constant maintenance (updates, deletes, freezing, etc.). It also might
> make it possible to move to 64-bit xids, if we wanted to.
If
Bruce Momjian wrote:
> xact_start | timestamp with time zone |
> query_start | timestamp with time zone |
> backend_start| timestamp with time zone |
> Should we move query_start?
It would scan better, to my mind, if we moved backend_start ahead of
xact_start.
And paint i
Bruce Momjian writes:
> That's a possibility, but we obviously have been adding columns
> out-of-order for several releases now and no one has complained.
On balance I'm for rationalizing this. The query_start time is
logically associated with current_query and waiting, so it ought
to be next to
On Tue, 2010-03-16 at 15:29 +, Greg Stark wrote:
> I'm picturing storing a bit in the visibility map indicating that *no*
> records are visible in a given page.
I've been thinking for a while that we could store the visibility
information in a structure separate from the heap -- sort of like t
Magnus Hagander wrote:
> On Wed, Mar 17, 2010 at 21:42, Bruce Momjian wrote:
> > Has anyone ever noticed that the order of pg_stat_activity timestamp
> > columns is illogical:
> >
> > ?xact_start ? ? ? | timestamp with time zone |
> > ?query_start ? ? ?| timestamp with time zone |
> > ?backend_sta
On Sat, 2009-09-19 at 13:21 -0400, Tom Lane wrote:
> I realized the truth of $SUBJECT while reading this report:
> http://archives.postgresql.org/pgsql-general/2009-09/msg00712.php
...
> Also, does this have any impact on the Hot Standby stuff?
It could potentially, but there is not much HS-rela
On Sat, 2010-03-13 at 11:26 -0800, Josh Berkus wrote:
> > The list has been reduced greatly in the past week. What about HS/SR
> > open items?
>
> I'd like to see vacuum_defer_cleanup_age added to the "Archive" section
> of postgresql.conf,
Not all parameters are in postgresql.conf.sample. Encou
On Wed, Mar 17, 2010 at 21:42, Bruce Momjian wrote:
> Has anyone ever noticed that the order of pg_stat_activity timestamp
> columns is illogical:
>
> xact_start | timestamp with time zone |
> query_start | timestamp with time zone |
> backend_start | timestamp with time zone |
W
On Tue, 2010-03-16 at 15:29 +, Greg Stark wrote:
> big batch delete
Is one of the reasons for partitioning, allowing the use of truncate.
--
Simon Riggs www.2ndQuadrant.com
--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscripti
Has anyone ever noticed that the order of pg_stat_activity timestamp
columns is illogical:
xact_start | timestamp with time zone |
query_start | timestamp with time zone |
backend_start| timestamp with time zone |
query_start is always between the other two timestamps. Moving
q
> Not aware of any issues - certainly none cropped up in QA. In fact,
> this release should fix one of the long standing initdb failures we
> see occasionally on some secure environments.
OK, I'll ask on our mailing list.
--
-- Josh Berkus
On Wed, Mar 17, 2010 at 5:02 PM, Josh Berkus wrote:
>
>> Yes there: http://www.enterprisedb.com/products/pgdevdownload.do
>>
>> We've produced them since Alpha 2 iirc.
>
> Oh! Most people don't know about these ... I need to advertise them!
They're linked from here, which you may want to update
> Yes there: http://www.enterprisedb.com/products/pgdevdownload.do
>
> We've produced them since Alpha 2 iirc.
Oh! Most people don't know about these ... I need to advertise them!
BTW, at SFPUG there were reports of some kind of issue with the
One-Click installer for 8.4.3. Is that resolved,
On Wed, Mar 17, 2010 at 4:54 PM, Josh Berkus wrote:
> All,
>
>
> A user at SFPUG last night pointed out why we should release a beta,
> rather than an alpha, sooner rather than later: because there are no
> Windows packages for Alphas.
Yes there: http://www.enterprisedb.com/products/pgdevdownloa
All,
A user at SFPUG last night pointed out why we should release a beta,
rather than an alpha, sooner rather than later: because there are no
Windows packages for Alphas.
Currently, our Windows users are *not* testing 9.0. Which means we're
just putting off the day when we hear about Windows
Hitoshi Harada writes:
> 2010/3/17 Tom Lane :
>> When we were doing the ordered-aggregates patch, I considered passing
>> all those values as explicit parameters to transformAggregateCall,
>> and having it build the Aggref node from scratch and return it.
>> However having seven or eight parameter
Pavel Golub writes:
> Here I created user-defined type "my_varchar" for internal tests. But
> PQftype returns 1043 (varchar oid) for the "info" column.
Really? I tried it and got 172069, which is about right for where the
OID counter is in my database. I think you messed up your test.
On Wed, Mar 17, 2010 at 01:55:45PM +0600, Dmitry Fefelov wrote:
> > Here is a revised partitioning syntax patch. It implements only syntax and
> > on-disk structure mentioned below:
> > Table Partitioning#Syntax
> > http://wiki.postgresql.org/wiki/Table_partitioning#Syntax
> > Table P
On 17.03.10 4:08 , Merlin Moncure wrote:
On Tue, Mar 16, 2010 at 5:53 PM, Florian
Pflug wrote:
which returns the field named from the record. The
expected field type is specified by providing a default value
in of the expected type. Since that argument's type is
ANYELEMENT, just like the retu
On Wed, 2010-03-17 at 12:35 +0200, Heikki Linnakangas wrote:
> Looking into this, I realized that we have a bigger problem...
A lot of this would be easier if you do the docs first, then work
through the problems. The new system is more complex, since it has two
modes rather than one and also mul
Fujii Masao wrote:
> I found another missing feature in new file-based log shipping (i.e.,
> standby_mode is enabled and 'cp' is used as restore_command).
>
> After the trigger file is found, the startup process with pg_standby
> tries to replay all of the WAL files in both pg_xlog and the archive
Greg Stark wrote:
> On Wed, Mar 17, 2010 at 9:37 AM, Heikki Linnakangas
> wrote:
>> One awkward omission in the new built-in standby mode, mainly used for
>> streaming replication, is that there is no easy way to delete old
>> archived files like you do with the %r parameter to restore_command.
>
On Wed, Mar 17, 2010 at 9:37 AM, Heikki Linnakangas
wrote:
> One awkward omission in the new built-in standby mode, mainly used for
> streaming replication, is that there is no easy way to delete old
> archived files like you do with the %r parameter to restore_command.
I'm still finding this kin
One awkward omission in the new built-in standby mode, mainly used for
streaming replication, is that there is no easy way to delete old
archived files like you do with the %r parameter to restore_command.
This was discussed at
http://archives.postgresql.org/pgsql-hackers/2010-02/msg01003.php, amon
Hello, Pgsql-hackers.
The script:
CREATE TYPE my_varchar;
CREATE OR REPLACE FUNCTION my_varcharout(my_varchar)
RETURNS cstring AS
'varcharout'
LANGUAGE 'internal' IMMUTABLE STRICT
COST 1;
CREATE OR REPLACE FUNCTION my_varcharin(cstring, oid, integer)
RETURNS my_varchar AS
'varcharin'
>
>
> When we were doing the ordered-aggregates patch, I considered passing
> all those values as explicit parameters to transformAggregateCall,
> and having it build the Aggref node from scratch and return it.
> However having seven or eight parameters to transformAggregateCall
> (and more in futu
Dmitry Fefelov wrote:
> > Here is a revised partitioning syntax patch. It implements only syntax and
> > on-disk structure mentioned below:
> > Table Partitioning#Syntax
> > http://wiki.postgresql.org/wiki/Table_partitioning#Syntax
> > Table Partitioning#On-disk structure
> >
> Here is a revised partitioning syntax patch. It implements only syntax and
> on-disk structure mentioned below:
> Table Partitioning#Syntax
> http://wiki.postgresql.org/wiki/Table_partitioning#Syntax
> Table Partitioning#On-disk structure
> http://wiki.postgresql.org/wiki/Tabl
> Here is a revised partitioning syntax patch. It implements only syntax and
> on-disk structure mentioned below:
> Table Partitioning#Syntax
> http://wiki.postgresql.org/wiki/Table_partitioning#Syntax
> Table Partitioning#On-disk structure
> http://wiki.postgresql.org/wiki/Tabl
45 matches
Mail list logo
