I have done my yearly TODO list cleanup, and I did more extensive item
removal this time. There were a number of entries I could not figure out
so if people want to review what is left and remove items that are
undesired or done, please do that. Thanks.
https://wiki.postgresql.org/wiki/T
On Mon, Dec 21, 2015 at 07:54:43AM -0500, Robert Haas wrote:
> On Thu, Jul 9, 2015 at 4:49 PM, Jeff Janes wrote:
> > Is there anything in the below section which has been been implemented or
> > rendered irrelevant by BRIN indexes?
> >
> > https://wiki.postgresql.org/wiki/Todo#Indexes
> >
> > "Con
On 21 December 2015 at 14:38, Robert Haas wrote:
> On Mon, Dec 21, 2015 at 8:06 AM, Simon Riggs
> wrote:
> > On 21 December 2015 at 12:54, Robert Haas wrote:
> >>
> >> On Thu, Jul 9, 2015 at 4:49 PM, Jeff Janes
> wrote:
> >> > Is there anything in the below section which has been been implemen
On Mon, Dec 21, 2015 at 8:06 AM, Simon Riggs wrote:
> On 21 December 2015 at 12:54, Robert Haas wrote:
>>
>> On Thu, Jul 9, 2015 at 4:49 PM, Jeff Janes wrote:
>> > Is there anything in the below section which has been been implemented
>> > or
>> > rendered irrelevant by BRIN indexes?
>> >
>> > h
On 21 December 2015 at 12:54, Robert Haas wrote:
> On Thu, Jul 9, 2015 at 4:49 PM, Jeff Janes wrote:
> > Is there anything in the below section which has been been implemented or
> > rendered irrelevant by BRIN indexes?
> >
> > https://wiki.postgresql.org/wiki/Todo#Indexes
> >
> > "Consider smal
On Thu, Jul 9, 2015 at 4:49 PM, Jeff Janes wrote:
> Is there anything in the below section which has been been implemented or
> rendered irrelevant by BRIN indexes?
>
> https://wiki.postgresql.org/wiki/Todo#Indexes
>
> "Consider smaller indexes that record a range of values per heap page,
> rather
On 16 October 2015 18:20:59 EEST, Bruce Momjian wrote:
>I think on-disk bitmap indexes would only beat GIN indexes in a
>read-only database on low-cardinality columns. For example, if you had
>a purchase_log table and wanted to know all the "blue" and "large"
>items
>sold at a specific store, I
On Fri, Oct 16, 2015 at 12:02:03PM -0300, Alvaro Herrera wrote:
> Bruce Momjian wrote:
>
> > Are you suggesting I remove those links? It is kind of odd to have
> > links to patches for features we don't want, or just keep it?
>
> No, quite the contrary -- I think the links allow some other perso
On Fri, Oct 16, 2015 at 12:00:11PM -0300, Alvaro Herrera wrote:
> Bruce Momjian wrote:
> > I have spend the past few days updating our TODO list, removing
> > completed and now-unnecessary items:
> >
> > https://wiki.postgresql.org/wiki/Todo
>
> Thanks. We have "TodoDone" pages for items tha
Bruce Momjian wrote:
> Are you suggesting I remove those links? It is kind of odd to have
> links to patches for features we don't want, or just keep it?
No, quite the contrary -- I think the links allow some other person
research the issue including the history of patches and discussion, and
de
Bruce Momjian wrote:
> I have spend the past few days updating our TODO list, removing
> completed and now-unnecessary items:
>
> https://wiki.postgresql.org/wiki/Todo
Thanks. We have "TodoDone" pages for items that were done in specific
releases, but only for 8.4, 9.0 and 9.1. I guess it
On Fri, Oct 16, 2015 at 11:43:10AM -0300, Alvaro Herrera wrote:
> Bruce Momjian wrote:
>
> > Probably the most controvertial change was to move on-disk bitmap
> > indexes to the "not wanted" section, though I kept the links in case we
> > change our minds. I just can't see how they would be a win
Bruce Momjian wrote:
> Probably the most controvertial change was to move on-disk bitmap
> indexes to the "not wanted" section, though I kept the links in case we
> change our minds. I just can't see how they would be a win with GIN and
> in-memory bitmaps.
Yeah, I recall we discussed bitmap ind
On Fri, Oct 16, 2015 at 02:50:04PM +0530, Amit Kapila wrote:
> On Fri, Oct 16, 2015 at 8:34 AM, Bruce Momjian wrote:
>
> I have spend the past few days updating our TODO list, removing
> completed and now-unnecessary items:
>
> https://wiki.postgresql.org/wiki/Todo
>
>
>
>
On Fri, Oct 16, 2015 at 8:34 AM, Bruce Momjian wrote:
> I have spend the past few days updating our TODO list, removing
> completed and now-unnecessary items:
>
> https://wiki.postgresql.org/wiki/Todo
>
>
Thanks. It can help encourage many new entrants to community.
With Regards,
Amit
I have spend the past few days updating our TODO list, removing
completed and now-unnecessary items:
https://wiki.postgresql.org/wiki/Todo
I encourage others to also update the list to make it more accurate.
Thanks.
--
Bruce Momjian http://momjian.us
EnterpriseDB
Is there anything in the below section which has been been implemented or
rendered irrelevant by BRIN indexes?
https://wiki.postgresql.org/wiki/Todo#Indexes
"Consider smaller indexes that record a range of values per heap page,
rather than having one index entry for every heap row"
Cheers,
Jeff
I have removed the completed 9.2 TODO items so people can start updating
the TODO list completed items for 9.3.
--
Bruce Momjian http://momjian.us
EnterpriseDB http://enterprisedb.com
+ It's impossible for everything to be true. +
--
Sent via pgsql-ha
Alvaro Herrera wrote:
> Excerpts from Bruce Momjian's message of lun jul 11 18:58:35 -0400 2011:
> > I have updated the TODO wiki to remove the 9.1-completed items:
> >
> > http://wiki.postgresql.org/wiki/Todo
> >
> > This will allow us to now mark 9.2-completed items.
>
> I have created Tod
Excerpts from Bruce Momjian's message of lun jul 11 18:58:35 -0400 2011:
> I have updated the TODO wiki to remove the 9.1-completed items:
>
> http://wiki.postgresql.org/wiki/Todo
>
> This will allow us to now mark 9.2-completed items.
I have created TodoDone91 from the items marked TodoDone
Pavel Stehule wrote:
> Hello
>
> I use a LISTEN/NOTIFY. Now I have to check, if second application that
> creates channels is active. It should be simple with system view of
> active channels.
I think you want pg_listening_channels().
--
Bruce Momjian http://momjian.us
EnterpriseDB
I have updated the TODO wiki to remove the 9.1-completed items:
http://wiki.postgresql.org/wiki/Todo
This will allow us to now mark 9.2-completed items.
--
Bruce Momjian http://momjian.us
EnterpriseDB http://enterprisedb.com
+ It's impossible
Hello
I use a LISTEN/NOTIFY. Now I have to check, if second application that
creates channels is active. It should be simple with system view of
active channels.
Regards
Pavel Stehule
--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:
ht
Robert Haas wrote:
> On Thu, Jan 20, 2011 at 4:40 PM, Simone Aiken
> wrote:
> > After playing with this in benchmarks and researching the weird results I
> > got I'm going to advise dropping the todo for now unless something happens
> > to change how postgres handles clustering.
>
> I agree, let'
On Thu, Jan 20, 2011 at 4:40 PM, Simone Aiken
wrote:
> After playing with this in benchmarks and researching the weird results I
> got I'm going to advise dropping the todo for now unless something happens
> to change how postgres handles clustering.
I agree, let's remove it.
That having been sa
After playing with this in benchmarks and researching the weird results I
got I'm going to advise dropping the todo for now unless something happens
to change how postgres handles clustering. You guys probably already
grokked this so I am just recording it for the list archives.
The primary
On Wed, Jan 19, 2011 at 4:27 PM, Simone Aiken wrote:
> In my experience size increases related to documentation are almost always
> worth it. So I'm prejudiced right out of the gate. I was wondering if
> every pg_ table gets copied out to every database .. if there is already a
> mechanism for
>
>I seem to recall some muttering about teaching genbki to extract such
comments from the SGML sources or perhaps the C header files. I tend to
agree though that it would be a lot >more work than it's worth. And as you
say, pg_description entries aren't free.
>
I know I can't do all of the wor
Robert Haas writes:
> On Wed, Jan 19, 2011 at 3:10 PM, Tom Lane wrote:
>> Well, on my machine pg_description is about 210K (per database) as of
>> HEAD. 90% of its contents are pg_proc entries, though I have no good
>> fix on how much of that is for internal-use-only functions. A very
>> rough
On Wed, Jan 19, 2011 at 3:10 PM, Tom Lane wrote:
> Robert Haas writes:
>> On Wed, Jan 19, 2011 at 2:26 PM, Tom Lane wrote:
>>> Which brings up another point though. I have a personal TODO item to
>>> make the comments for operator support functions more consistent:
>>> http://archives.postgresql
Robert Haas writes:
> On Wed, Jan 19, 2011 at 2:26 PM, Tom Lane wrote:
>> Which brings up another point though. I have a personal TODO item to
>> make the comments for operator support functions more consistent:
>> http://archives.postgresql.org/message-id/21407.1287157...@sss.pgh.pa.us
>> Should
On Wed, Jan 19, 2011 at 2:26 PM, Tom Lane wrote:
> Robert Haas writes:
>> On Tue, Jan 18, 2011 at 6:49 PM, Simone Aiken
>> wrote:
>>> Pages like this one have column comments for the system tables:
>>>
>>> http://www.psql.it/manuale/8.3/catalog-pg-attribute.html
>
>> Oh, I see. I don't think we
Excerpts from Robert Haas's message of mié ene 19 15:25:00 -0300 2011:
> Oh, I see. I don't think we want to go there. We'd need some kind of
> system for keeping the two places in sync.
Maybe autogenerate both the .sgml and the postgres.description files
from a single source.
> And there'd be
Robert Haas writes:
> On Tue, Jan 18, 2011 at 6:49 PM, Simone Aiken
> wrote:
>> Pages like this one have column comments for the system tables:
>>
>> http://www.psql.it/manuale/8.3/catalog-pg-attribute.html
> Oh, I see. I don't think we want to go there. We'd need some kind of
> system for ke
On Tue, Jan 18, 2011 at 6:49 PM, Simone Aiken
wrote:
> Pages like this one have column comments for the system tables:
>
> http://www.psql.it/manuale/8.3/catalog-pg-attribute.html
Oh, I see. I don't think we want to go there. We'd need some kind of
system for keeping the two places in sync. An
> Robert
>
> I think the first
> thing to do would be to try to come up with a reproducible test case
> where clustering the tables improves performance.
>
On that note, is there any standard way you guys do benchmarks?
> Bruce
>
>I think CLUSTER is a win when you are looking up multiple
-Original Message-
From: Robert Haas [mailto:robertmh...@gmail.com]
Sent: Tuesday, January 18, 2011 2:53 PM
To: Simone Aiken
Cc: Alvaro Herrera; pgsql-hackers
Subject: Re: [HACKERS] ToDo List Item - System Table Index Clustering
>Sure - my point is just that we usually have a
On Tue, Jan 18, 2011 at 12:16 PM, Simone Aiken wrote:
> When I'm learning a new system I like to first learn how to use it,
> second learn its data model, third start seriously looking at the code.
> So that Todo is ideal for my learning method.
Sure - my point is just that we usually have as a c
Robert Haas wrote:
> On Tue, Jan 18, 2011 at 8:35 AM, Alvaro Herrera
> wrote:
> > Excerpts from Simone Aiken's message of dom ene 16 02:11:26 -0300 2011:
> >>
> >> Hello Postgres Hackers,
> >>
> >> In reference to this todo item about clustering system table indexes,
> >> ( http://archives.postgre
On Tue, Jan 18, 2011 at 8:35 AM, Alvaro Herrera
wrote:
>> Excerpts from Simone Aiken's message of dom ene 16 02:11:26 -0300 2011:
>>>
>> >Hello Postgres Hackers,
>>>
>> >In reference to this todo item about clustering system table indexes,
>>> ( http://archives.postgresql.org/pgsql-hackers/2004
On Jan 18, 2011, at 6:35 AM, Alvaro Herrera wrote:
>>
>
> Wow, this is really old stuff. I don't know if this is really of any
> benefit, given that these catalogs are loaded into syscaches anyway.
The benefit is educational primarily. I was looking for a todo list item
that would expose me
On Tue, Jan 18, 2011 at 8:35 AM, Alvaro Herrera
wrote:
> Excerpts from Simone Aiken's message of dom ene 16 02:11:26 -0300 2011:
>>
>> Hello Postgres Hackers,
>>
>> In reference to this todo item about clustering system table indexes,
>> ( http://archives.postgresql.org/pgsql-hackers/2004-05/msg00
Excerpts from Simone Aiken's message of dom ene 16 02:11:26 -0300 2011:
>
> Hello Postgres Hackers,
BTW whatever you do, don't start a new thread by replying to an existing
message and just changing the subject line. It will mess up the
threading for some readers, and some might not even see you
Excerpts from Simone Aiken's message of dom ene 16 02:11:26 -0300 2011:
>
> Hello Postgres Hackers,
>
> In reference to this todo item about clustering system table indexes,
>
> ( http://archives.postgresql.org/pgsql-hackers/2004-05/msg00989.php )
> I have been studying the system ta
Followup on System Table Index clustering ToDo -
It looks like to implement this I need to do the following:
1 - Add statements to indexing.h to cluster the selected indexes.
A do-nothing define at the top to suppress warnings and then
lines below for perl to pars
>> Select typoutput::oid from pg_type limit 1;
> Also, you *can* go back the other way. It's very common to write
>
> Select * from pg_proc where oid = 'boolout'::regproc
>
> rather than looking up the OID first.
> see "Object Identifier Types" in the manual.
Many thanks
Nicolas Barbier writes:
> 2011/1/16 Simone Aiken :
>>... So even though the documentation says that column
>>maps to pg_proc.oid I can't then write:
>>Select * from pg_proc where oid = 'boolout';
> Type type of typoutput is "regproc", which is really an oid with a
2011/1/16 Simone Aiken :
> is there a way to make queries on the system tables show me what
> is actually there when I'm poking around? So for example:
>
> Select * from pg_type limit 1;
>
> tells me that the typoutput is 'boolout'. An english string rather
>
Hello Postgres Hackers,
In reference to this todo item about clustering system table indexes,
( http://archives.postgresql.org/pgsql-hackers/2004-05/msg00989.php )
I have been studying the system tables to see which would benefit from
clustering. I have some index suggestions and a
2010/3/27 Tom Lane :
> Robert Haas writes:
>> In reading through the TODO list, I noticed a few things that I think
>> are done, may be done, or may be partially done. See below.
>> Thoughts? ...Robert
>
>> Implement full support for window framing clauses.
>> - Not sure if we made any progress
Robert Haas wrote:
> In reading through the TODO list, I noticed a few things that I think
> are done, may be done, or may be partially done. See below.
> Thoughts? ...Robert
>
> Add missing operators for geometric data types
> - this is at least partly done. not sure if it is entirely done.
>
Tom Lane wrote:
> Robert Haas writes:
> > In reading through the TODO list, I noticed a few things that I think
> > are done, may be done, or may be partially done. See below.
> > Thoughts? ...Robert
>
> > Add missing operators for geometric data types
> > - this is at least partly done. not s
Robert Haas writes:
> As far as I know, exclusion constraints would work with hash opclasses
> also.
Yeah, they do.
> Do you think there's an advantage to having something that is
> hash-specific a la the btree-specific stuff we already have?
Sure: it'll be more efficient because of not needing
On Fri, Mar 26, 2010 at 12:57 PM, Tom Lane wrote:
> Robert Haas writes:
>> In reading through the TODO list, I noticed a few things that I think
>> are done, may be done, or may be partially done. See below.
>> Thoughts? ...Robert
>
>> Add missing operators for geometric data types
>> - this is
Robert Haas writes:
> In reading through the TODO list, I noticed a few things that I think
> are done, may be done, or may be partially done. See below.
> Thoughts? ...Robert
> Add missing operators for geometric data types
> - this is at least partly done. not sure if it is entirely done.
I
In reading through the TODO list, I noticed a few things that I think
are done, may be done, or may be partially done. See below.
Thoughts? ...Robert
Add missing operators for geometric data types
- this is at least partly done. not sure if it is entirely done.
Add OR REPLACE to CREATE LANGUAG
> Allowing foreign keys to point to expression indexes seems to open a can
> of worms and I am not sure there is enough demand to warrant it.
It does open a can of worms. I've often wanting something related,
which is the ability to make a foreign key references a PARTIAL index.
...Robert
--
S
David E. Wheeler wrote:
> On Nov 19, 2008, at 9:12 AM, Josh Berkus wrote:
>
> > Folks,
> >
> > Since it's too late to look at this for 8.4, can the following go on
> > the TODO list?
> >
> > Referential Integrity
> >
> > [] Allow creation of FKs targeting unique expression indexes on the
> > r
On Nov 19, 2008, at 9:12 AM, Josh Berkus wrote:
Folks,
Since it's too late to look at this for 8.4, can the following go on
the TODO list?
Referential Integrity
[] Allow creation of FKs targeting unique expression indexes on the
referenced table. Syntax: REFERENCES ( ( column
express
Folks,
Since it's too late to look at this for 8.4, can the following go on the
TODO list?
Referential Integrity
[] Allow creation of FKs targeting unique expression indexes on the
referenced table. Syntax: REFERENCES ( ( column expression ) )
Reason: current FK rules do not allow creati
Tom Lane wrote:
> Bruce Momjian <[EMAIL PROTECTED]> writes:
> > Tom Lane wrote:
> >> Actually, the part of the current process that a wiki would fail to
> >> reproduce is the emails that Bruce sends out about TODO changes.
> >> Do we still want those, and if so what would we do about it?
>
> > Mag
Tom Lane wrote:
> Magnus Hagander <[EMAIL PROTECTED]> writes:
> > On Wed, Mar 12, 2008 at 11:03:13AM -0400, Bruce Momjian wrote:
> >> We need it to do a few things:
>
> Actually, the part of the current process that a wiki would fail to
> reproduce is the emails that Bruce sends out about TODO cha
Bruce Momjian <[EMAIL PROTECTED]> writes:
> Tom Lane wrote:
>> Actually, the part of the current process that a wiki would fail to
>> reproduce is the emails that Bruce sends out about TODO changes.
>> Do we still want those, and if so what would we do about it?
> Magnus said you can subscribe to
On Wed, Mar 12, 2008 at 11:36:52AM -0400, Tom Lane wrote:
> Magnus Hagander <[EMAIL PROTECTED]> writes:
> > On Wed, Mar 12, 2008 at 11:03:13AM -0400, Bruce Momjian wrote:
> >> We need it to do a few things:
>
> Actually, the part of the current process that a wiki would fail to
> reproduce is the
Magnus Hagander <[EMAIL PROTECTED]> writes:
> On Wed, Mar 12, 2008 at 11:03:13AM -0400, Bruce Momjian wrote:
>> We need it to do a few things:
Actually, the part of the current process that a wiki would fail to
reproduce is the emails that Bruce sends out about TODO changes.
Do we still want those
On Wed, Mar 12, 2008 at 11:03:13AM -0400, Bruce Momjian wrote:
> Magnus Hagander wrote:
> > > If you change the text file, I will see the CVS update and update the
> > > HTML --- I will never lose a change because my CVS sees your changes.
> >
> > That seems like a lot of extra work that should be
On Wed, Mar 12, 2008 at 10:27:06AM -0400, Bruce Momjian wrote:
> Alvaro Herrera wrote:
> > Bruce Momjian wrote:
> > > Magnus Hagander wrote:
> >
> > > > It's not. And I personally don't think it would be a problem.
> > > > But I think it'll be a lot easier to sell to those who prefer
> > > > textf
I have removed the developer names from the bottom of the TODO list now
that URLs are used to reference discussions. The URLs are much more
accurate than putting names on items.
--
Bruce Momjian [EMAIL PROTECTED]
EnterpriseDBhttp://www.enterprisedb.com
+ If your life is a hard drive
On Sun, 2006-12-17 at 10:56 +0100, Lukas Kahwe Smith wrote:
> PostgreSQL 8.2 is out of the door. Unfortunately the plans for a more
> detailed todo list have not come into reality yet to assist in for the
> next 8.3 release. A couple people have replied to my earlier request to
> form a little
Hi,
PostgreSQL 8.2 is out of the door. Unfortunately the plans for a more
detailed todo list have not come into reality yet to assist in for the
next 8.3 release. A couple people have replied to my earlier request to
form a little team willing to work on this, but unfortunately people
seem to
On Fri, Aug 26, 2005 at 03:44:18PM -0400, Bruce Momjian wrote:
> Jim C. Nasby wrote:
> > I *think* this is reffering to how pg_dump makes some assumptions about
> > what things are system objects.
> >
> > http://archives.postgresql.org/pgsql-committers/2005-08/msg00203.php
> > doesn't help a heck
Andrew Dunstan wrote:
>
>
> Tom Lane wrote:
>
> >Or perhaps use a different separator:
> >
> >junk=# select * from xyz;
> > id |name| address | del_addr
> >++---+--
> >
Jim C. Nasby wrote:
> I *think* this is reffering to how pg_dump makes some assumptions about
> what things are system objects.
>
> http://archives.postgresql.org/pgsql-committers/2005-08/msg00203.php
> doesn't help a heck of a lot...
>
> Can we add an interface to the TODO list that contains sea
Hannu Krosing wrote:
> On K, 2005-08-24 at 21:58 -0400, Tom Lane wrote:
> > > * %Allow TRUNCATE ... CASCADE/RESTRICT
> >
> > Huh? What would that do?
>
> Maybe this was meant truncating of tables with dependent foreign keys ?
>
> AFAIR this was solved by allowing truncating several tables in on
Alvaro Herrera wrote:
> On Thu, Aug 25, 2005 at 01:53:32PM -, Greg Sabino Mullane wrote:
>
> > Tom Lane asked:
> >
> > >> o Improve psql's handling of multi-line queries
> >
> > > Uh, what's wrong with it? This item seems far too vague.
> >
> > I think perhaps this means adding multi
Great updates! Let me comment on each one.
> I made a pass over the TODO list to see what was out of date.
>
> > * Allow administrators to safely terminate individual sessions either
> > via an SQL function or SIGTERM
> >
> > Currently SIGTERM of a backend can lead to lock table corruptio
On Aug 25, 2005, at 11:29 PM, Matt Miller wrote:
On Thu, 2005-08-25 at 15:50 +0900, Michael Glaesemann wrote:
* %Remove CREATE CONSTRAINT TRIGGER
Do we really want to remove it,
Also, I believe CONSTRAINT TRIGGERS are the only way to provide
transaction level (rather than statement
On Wed, Aug 24, 2005 at 09:58:04PM -0400, Tom Lane wrote:
> > * %Allow RULE recompilation
>
> Eh? Perhaps you meant "automatically regenerate cached plans when
> needed", in which case it's redundant with the Dependency Checking
> entries. Whatever it means, this doesn't seem a particularly simp
Tom Lane wrote:
Or perhaps use a different separator:
junk=# select * from xyz;
id |name| address | del_addr
++---+--
1 | Joe Bloggs | 1 Hindhead Villas,
Oliver Elphick writes:
> It would be better to show the columns aligned (perhaps without showing
> separators for other columns so as not to give the impression that the
> other columns contain null or empty strings):
> junk=# select * from xyz;
> id |name| address
On Thu, 2005-08-25 at 13:53 +, Greg Sabino Mullane wrote:
> -BEGIN PGP SIGNED MESSAGE-
> Hash: SHA1
>
>
> Tom Lane asked:
>
> >> o Improve psql's handling of multi-line queries
>
> > Uh, what's wrong with it? This item seems far too vague.
If you enter a multi-line query one
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
Tom Lane asked:
>> o Improve psql's handling of multi-line queries
> Uh, what's wrong with it? This item seems far too vague.
I think perhaps this means adding multi-line support to
the tab-completion? Only thing I can think of, cause other
On Thu, Aug 25, 2005 at 01:53:32PM -, Greg Sabino Mullane wrote:
> Tom Lane asked:
>
> >> o Improve psql's handling of multi-line queries
>
> > Uh, what's wrong with it? This item seems far too vague.
>
> I think perhaps this means adding multi-line support to
> the tab-completion? O
On Thu, 2005-08-25 at 15:50 +0900, Michael Glaesemann wrote:
> >> * %Remove CREATE CONSTRAINT TRIGGER
> >>
> > Do we really want to remove it,
>
> Also, I believe CONSTRAINT TRIGGERS are the only way to provide
> transaction level (rather than statement level) referential
> integrity.
Don't d
On Wed, 2005-08-24 at 21:58, Tom Lane wrote:
> > o Add pg_dumpall custom format dumps.
> >
> > This is probably best done by combining pg_dump and pg_dumpall
> > into a single binary.
>
> This is probably obsoleted by events, too. Now that we can dump blobs
> in text mode, I see
On K, 2005-08-24 at 21:58 -0400, Tom Lane wrote:
> > * %Allow TRUNCATE ... CASCADE/RESTRICT
>
> Huh? What would that do?
Maybe this was meant truncating of tables with dependent foreign keys ?
AFAIR this was solved by allowing truncating several tables in one
command even if they have FK relati
On Aug 25, 2005, at 10:58 AM, Tom Lane wrote:
* %Remove CREATE CONSTRAINT TRIGGER
This was used in older releases to dump referential integrity
constraints.
Do we really want to remove it, and thereby guarantee we can't load
dumps from those old releases?
Also, I believe CONSTRAINT TR
Kris Jurka <[EMAIL PROTECTED]> writes:
> On Wed, 24 Aug 2005, Tom Lane wrote:
>> This is done (see bitmap index scans).
> Will the optimizer ever choose this plan when dealing with only one index?
Certainly. It's actually likely to prefer a bitmap scan whenever the
query is estimated to fetch mo
On Wed, 24 Aug 2005, Tom Lane wrote:
* Fetch heap pages matching index entries in sequential order
Rather than randomly accessing heap pages based on index entries, mark
heap pages needing access in a bitmap and do the lookups in sequential
order. Another method would be to sort heap ct
I made a pass over the TODO list to see what was out of date.
> * Allow administrators to safely terminate individual sessions either
> via an SQL function or SIGTERM
>
> Currently SIGTERM of a backend can lead to lock table corruption.
This comment may be out of date. Suggest
Loc
Bruce Momjian wrote:
Andrew Dunstan wrote:
Bruce Momjian wrote:
Andrew Dunstan wrote:
I thought we had thrashed this out back in August. Certainly the only
thing I recall seeing after I submitted the patch was some stylistic
criticism from Neil, which I addressed in a revised pa
Jon Jensen wrote:
On Tue, 6 Jan 2004, Andrew Dunstan wrote:
Also, I would like to see some kind of session identifier that is more
unique than pid, which wraps around. Ideally we could have 10{pid},
then then the pid wraps around, 20{pid), or something like that.
This requires some t
Andrew Dunstan wrote:
>
>
> Bruce Momjian wrote:
>
> >Andrew Dunstan wrote:
> >
> >
> >>I thought we had thrashed this out back in August. Certainly the only
> >>thing I recall seeing after I submitted the patch was some stylistic
> >>criticism from Neil, which I addressed in a revised patch.
Am Tuesday 06 January 2004 21:30 schrieb Jon Jensen:
> On Tue, 6 Jan 2004, Andrew Dunstan wrote:
> > >Also, I would like to see some kind of session identifier that is more
> > >unique than pid, which wraps around. Ideally we could have 10{pid},
> > >then then the pid wraps around, 20{pid), or som
On Tue, 6 Jan 2004, Andrew Dunstan wrote:
> >Also, I would like to see some kind of session identifier that is more
> >unique than pid, which wraps around. Ideally we could have 10{pid},
> >then then the pid wraps around, 20{pid), or something like that.
>
> This requires some thought. ISTM it w
Bruce Momjian wrote:
Andrew Dunstan wrote:
I thought we had thrashed this out back in August. Certainly the only
thing I recall seeing after I submitted the patch was some stylistic
criticism from Neil, which I addressed in a revised patch.
Anyway, it is in principle doable. That's partly why
Andrew Dunstan wrote:
> Bruce Momjian said:
> > Andrew Dunstan wrote:
> >>
> >> 2 things.
> >>
> >> I submitted a patch for this 5 months ago, which is still waiting to
> be merged (hope it hasn't bitrotted in the meantime):
> >>
> >> . Allow log lines to include session-level information, like da
Bruce Momjian said:
> Andrew Dunstan wrote:
>>
>> 2 things.
>>
>> I submitted a patch for this 5 months ago, which is still waiting to
be merged (hope it hasn't bitrotted in the meantime):
>>
>> . Allow log lines to include session-level information, like database
and user
>>
>> If nobody is worki
Andrew Dunstan wrote:
>
> 2 things.
>
> I submitted a patch for this 5 months ago, which is still waiting to be
> merged (hope it hasn't bitrotted in the meantime):
>
> . Allow log lines to include session-level information, like database
> and user
>
> If nobody is working on this I am prepa
2 things.
I submitted a patch for this 5 months ago, which is still waiting to be
merged (hope it hasn't bitrotted in the meantime):
. Allow log lines to include session-level information, like database
and user
If nobody is working on this I am prepared to look at it:
. Allow logging of only
1 - 100 of 129 matches
Mail list logo
