On Mon, 23 Mar 2009, Tom Lane wrote:
We used to have the stats_reset_on_server_start thingy, which covered
that case. When we removed it on the grounds that you could do the
same less klugily with pg_stat_reset(), nobody complained about
cluster-wide stats...
Not exactly sure of the sequence
Greg Smith writes:
> I'm curious why something resetting the cluster-wide stats isn't
> available already.
We used to have the stats_reset_on_server_start thingy, which covered
that case. When we removed it on the grounds that you could do the
same less klugily with pg_stat_reset(), nobody comp
Jeff Davis writes:
> On Mon, 2009-03-23 at 15:23 -0400, Tom Lane wrote:
>> There is no need for any such infrastructure if we just drive it off a
>> post-ANALYZE callback.
> That sounds reasonable, although it does seem a little strange for
> analyze to actually perform cleanup.
My thought was t
There are a few statistics that are only kept on a per-cluster basis, such
as those reported in pg_stat_database and pg_stat_bgwriter. Since
pg_stat_reset only resets per-database counts, it doesn't touch those.
I'd like to have a function that resets those. Maybe iterates over all
the datab
Andrew Gierth writes:
> "Tom" == Tom Lane writes:
> Tom> A defining SQL script is the way to go.
> But I disagree with this, for the simple reason that we don't have
> anything like enough flexibility in the form of conditional DDL or
> error handling, when working in pure SQL without any proce
On Mon, 2009-03-23 at 15:23 -0400, Tom Lane wrote:
> There is no need for any such infrastructure if we just drive it off a
> post-ANALYZE callback.
That sounds reasonable, although it does seem a little strange for
analyze to actually perform cleanup.
Now that we have FSM, the cost of VACUUMing
On 3/19/09 2:40 PM, Dimitri Fontaine wrote:
Hi,
Le 19 mars 09 à 21:23, Josh Berkus a écrit :
One request I've had is to construct a record (of some supplied
composite type) from an hstore.
I'm not sure if this is even possible; I'm certainly not seeing a way
to implement it. Am I missing somet
> "Tom" == Tom Lane writes:
Tom> I think the way most people are envisioning this is that a
Tom> module is a set of SQL objects (functions, types, tables,
Tom> whatever). Whether any of those are C functions in one or more
Tom> underlying .so files is not really particularly relevant to
On Mon, 2009-03-23 at 16:21 -0400, Bruce Momjian wrote:
> If a platform doesn't have posix_fadvise(), we don't allow
> effective_io_concurrency to be set to anything but zero:
>
> test=> set effective_io_concurrency = 1;
> ERROR: 1 is outside the valid range for parameter
> "effecti
If a platform doesn't have posix_fadvise(), we don't allow
effective_io_concurrency to be set to anything but zero:
test=> set effective_io_concurrency = 1;
ERROR: 1 is outside the valid range for parameter
"effective_io_concurrency" (0 .. 0)
test=> set effective_io_con
Le 23 mars 09 à 20:33, Robert Haas a écrit :
It may well be that the table has data in it that was inserted after
module creation time, and the user may want it preserved with the
upgrade, but there's really no way to even begin to guess what the
user had in mind here.
Exactly, we're not in the
On Mon, Mar 23, 2009 at 7:46 AM, Dimitri Fontaine
wrote:
> On Monday 23 March 2009 12:34:31 Robert Haas wrote:
>> That might not be the only time you ever want to create dependencies
>> on the module object. What if the module wants to create an
>> additional table, view, etc. at some later time,
Alvaro Herrera writes:
> Tom Lane wrote:
>> On top of those issues, there are implementation problems in the
>> proposed relation_has_pending_indexes() check:
> I wonder if it's workable to have GIN send pgstats a message with number
> of fast-inserted tuples, and have autovacuum check that numbe
While I'm looking at this thing...
Why is tbm_add_page() not coded as a simple wrapper around
tbm_mark_page_lossy()? As coded, it sometimes forces a whole bunch of
pages *other than* the target page to become lossy too, which I cannot
see a reason for it to be doing.
rega
Tom Lane wrote:
> On top of those issues, there are implementation problems in the
> proposed relation_has_pending_indexes() check: it has hard-wired
> knowledge about GIN indexes, which means the feature cannot be
> extended to add-on index AMs; and it's examining indexes without any
> lock whats
I'm looking again at the fast-insert patch, and I find myself still
desperately unhappy about the mechanism for scheduling autovacuum
cleanup of pending insertions. I complained about that before, but
I think I only cited a worry about adding overhead to statistics
tracking in order to have the "r
On Monday 23 March 2009 15:43:04 Tom Lane wrote:
> I think the way most people are envisioning this is that a module is a
> set of SQL objects (functions, types, tables, whatever). Whether any
> of those are C functions in one or more underlying .so files is not
> really particularly relevant to t
I wrote:
> Attached is the remainder of the patch with relatively minor fixes.
> The main change I made is to get rid of the changes in gincostestimate;
> I agree with Robert that it's probably inappropriate to consider the
> current pending-list size during planning. I haven't really reviewed
> a
Dimitri Fontaine writes:
> On Sunday 22 March 2009 22:46:20 Tom Lane wrote:
>> You really haven't convinced me that this is anything but
>> overcomplication.
> Thinking about it some more what could be convincing is that an extension
> could be made of only SQL, with no module (.so) (I have a ca
-BEGIN PGP SIGNED MESSAGE-
Hash: RIPEMD160
> That being said i recognize that people who have dozens of child tables
> might get annoyed by this patch.
Dozens is on the low end: there are often a dozen dozen or more.
> Here's 3 ideas that could make things better :
>
> 1- When using \d
On Monday 23 March 2009 12:34:31 Robert Haas wrote:
> That might not be the only time you ever want to create dependencies
> on the module object. What if the module wants to create an
> additional table, view, etc. at some later time, following the load?
> I'm not sure whether there's a use case
Hi Kedar,
>
>
> The syntax used conforms to most of the suggestions mentioned in
> http://archives.postgresql.org/pgsql-hackers/2008-01/msg00413.php, barring
> the following:
> -- Specification of partition names is optional. System will be able to
> generate partition names in such cases.
> -- Su
On Sun, Mar 22, 2009 at 11:26 PM, Greg Stark
wrote:
> Why do you need any explicit syntax? If the database is loading an SQL file
> as a result of a LOAD MODULE command wouldn't it know to set whatever
> internal state it needs to remember that?
That might not be the only time you ever want to cr
The following list of patches are the initial revision of SE-PostgreSQL
on the v8.5 development cycle.
These are separated into several functional components to help review
and commit in earlier phase. Every patches (except for the core) have
abour 1KL scales. It is far smaller than them in a year
On Monday 23 March 2009 04:05:04 Andrew Gierth wrote:
> Dimitri> Heard about http://wiki.postgresql.org/wiki/ExtensionPackaging ?
> Yes, I left a short note on its discussion page a while ago :-)
Hehe... I'll answer here, as it's a more opened forum it seems...
Schemas vs Extensions (or modules,
On Sunday 22 March 2009 22:46:20 Tom Lane wrote:
> You really haven't convinced me that this is anything but
> overcomplication.
Thinking about it some more what could be convincing is that an extension
could be made of only SQL, with no module (.so) (I have a case here).
If a single .sql file c
Andrew Dunstan wrote:
Yes, dungbeetle is ... I took tcl out of its config until we had this
sorted out. Are you going to commit a _1.out file?
Done
--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgs
Hi.
I found a TODO item "Add dumping of comments on index columns and
composite type columns" for pg_dump
and want to write a patch for it.
But I'm not sure if I understand the problem correctly.
Does "Add dumping of comments on index columns" mean that
pg_dump should dump out COMMENT statements l
Hi.
I found a TODO item "Add dumping of comments on index columns and
composite type columns" for pg_dump
and want to write a patch for it.
But I'm not sure if I understand the problem correctly.
Does "Add dumping of comments on index columns" mean that
pg_dump should dump out COMMENT statements l
29 matches
Mail list logo
