Josh Berkus josh@agliodbs.com wrote
While I'm waiting to figure out how to get the size of the toast table,
at
least I can provide the speed of query with/without assumed compression
on
the 6K text columns.
Check out the table_size view in the newsysviews project. Andrew computed
the
Mark Woodward wrote:
If you require a policy, then YOU are free to choose the policy that
YOU need. You're not forced to accept other peoples' policies that
may conflict with things in your environment.
The problem is that there is no mechanism through which one can
implement
policy.
On Sun, 2006-02-26 at 19:26 -0500, Tom Lane wrote:
Simon Riggs [EMAIL PROTECTED] writes:
On Fri, 2006-02-10 at 11:58 -0500, Tom Lane wrote:
I suspect that the right thing is not to see this as a planner issue at
all, but to try to drive the choice off the context in which the plan
gets
Simon Riggs [EMAIL PROTECTED] writes:
On Sun, 2006-02-26 at 19:26 -0500, Tom Lane wrote:
After looking at my old notes about Materialize,
I am thinking that we should add a int flags parameter to the InitNode
calls along with ExecutorStart and probably PortalStart.
Design-wise I was looking
On Mon, Feb 27, 2006 at 09:39:59AM -0500, Mark Woodward wrote:
It isn't just an environment variable, it is a number of variables and a
mechanism. Besides, profile, from an admin's perspective, is for
managing users, not databases.
Sure, you need to control the user, group, placement of
Yeah it really was :-) BTW Ihave implemented this for multiuser-mode as well..Both the approaches as mentioned in my very first email...
1- The minimum super user count should not be less then 1.
2- Only the main database system owner is eligible to reassign.
My personal believe is, this
On Mon, Feb 27, 2006 at 09:39:59AM -0500, Mark Woodward wrote:
It isn't just an environment variable, it is a number of variables and
a
mechanism. Besides, profile, from an admin's perspective, is for
managing users, not databases.
Sure, you need to control the user, group, placement of
-Original Message-
From: [EMAIL PROTECTED]
[mailto:[EMAIL PROTECTED] On Behalf Of Mark Woodward
Sent: 27 February 2006 16:49
To: Martijn van Oosterhout
Cc: pgsql-hackers@postgresql.org
Subject: Re: [HACKERS] pg_config, pg_service.conf,
postgresql.conf
Think of Arthur
Subject says it all really. I've got a new client who seems to be
suffering from it, and I'm not sure if any conclusion was reached.
--
Richard Huxton
Archonet Ltd
---(end of broadcast)---
TIP 9: In versions below 8.0, the planner will ignore
Josh Berkus josh@agliodbs.com writes:
No way. The entire point of information_schema is that it is standard;
adding non-spec things to it renders it no better than direct access
to the PG catalogs.
Hmmm ... so, per you, we can't add extra views covering non-spec objects to
the
Richard Huxton dev@archonet.com writes:
Subject says it all really. I've got a new client who seems to be
suffering from it, and I'm not sure if any conclusion was reached.
What's he using? 8.1 seems to have alleviated the problem somewhat,
and I've done more work in CVS tip. It'll never go
Tom Lane wrote:
Richard Huxton dev@archonet.com writes:
Subject says it all really. I've got a new client who seems to be
suffering from it, and I'm not sure if any conclusion was reached.
What's he using? 8.1 seems to have alleviated the problem somewhat,
and I've done more work in CVS tip.
Richard Huxton dev@archonet.com writes:
Tom Lane wrote:
What's he using?
7.4.12 (.12 as of last week). I've seen context-switching peak at 8
on a quad-Xeon that really shouldn't be straining.
Try 8.1.3.
regards, tom lane
---(end of
Tom Lane wrote:
Richard Huxton dev@archonet.com writes:
Tom Lane wrote:
What's he using?
7.4.12 (.12 as of last week). I've seen context-switching peak at 8
on a quad-Xeon that really shouldn't be straining.
Try 8.1.3.
Thanks. I'll see if we can run a parallel installation overnight
On Mon, 2006-02-27 at 10:07 -0500, Tom Lane wrote:
Simon Riggs [EMAIL PROTECTED] writes:
On Sun, 2006-02-26 at 19:26 -0500, Tom Lane wrote:
After looking at my old notes about Materialize,
I am thinking that we should add a int flags parameter to the InitNode
calls along with
Hi,
The idea of using a so called dead space map to speed up vacuum has come
up multiple times in this list in the last couple of years. I wrote an
initial implementation of it to measure the performance impact it has on
updates and on vacuum.
Potential uses for a dead space map are:
*
Heikki,
On 2/27/06 9:53 AM, Heikki Linnakangas [EMAIL PROTECTED] wrote:
My current implementation stores a bitmap of 32k bits in the special space
of every 32k heap pages. Each bit in the bitmap corresponds one heap page.
The bit is set every time a tuple is updated, and it's cleared by
Heikki Linnakangas [EMAIL PROTECTED] writes:
Vacuum will need to be modified to use index lookups to find index tuples
corresponding the dead heap tuples. Otherwise you have to scan through
all the indexes anyway.
This strikes me as a fairly bad idea, because it makes VACUUM dependent
on
Something came to my mind today, I'm not sure if it's feasible but I
would like to know opinions on it.
We've seen database applications that PostgreSQL simply could not manage
because one would have to vacuum continuously. Perhaps in those
situations one could arrange it that an update (or
Hi All.
I have thought this way and that since that time. Suggestion of Magnus-san
was considered and this was made.
I considered many things about the pgpass guide of libpq. In windows, even
the place of it was not clear. Furthermore, they are intricately concerned
with an environment
On Mon, Feb 27, 2006 at 11:39:30AM -0500, Tom Lane wrote:
| Josh Berkus josh@agliodbs.com writes:
| No way. The entire point of information_schema is that it is standard;
| adding non-spec things to it renders it no better than direct access
| to the PG catalogs.
|
| Hmmm ... so, per you, we
Peter Eisentraut [EMAIL PROTECTED] writes:
We've seen database applications that PostgreSQL simply could not manage
because one would have to vacuum continuously. Perhaps in those
situations one could arrange it that an update (or delete) of a row
registers the space in the free space map
Hiroshi Saito [EMAIL PROTECTED] writes:
C:\Program Files\PostgreSQL\8.1\binpqpasswd.exe --help
pqpasswd installs a pgpass(libpq) connect a PostgreSQL database.
I must be missing something. What exactly does this accomplish that
couldn't be done at least as flexibly with a simple text editor?
On 2006-02-27, Tom Lane [EMAIL PROTECTED] wrote:
I do have doubts about adding any large number of add-on views to
pg_catalog, because of the privileged place of that schema in search
paths. It'd be better to put them in a separate schema (pg_info
maybe?) where they'd pose less risk of
Tom,
Hmmm ... so, per you, we can't add extra views covering non-spec objects to
the information_schema (like aggregates) because we can't modify it in any
way. But per Peter we can't add new views to the pg_catalog because we
want people to use information_schema. I sense a catch-22 here.
Thank you for a quick response.
From: Tom Lane
C:\Program Files\PostgreSQL\8.1\binpqpasswd.exe --help
pqpasswd installs a pgpass(libpq) connect a PostgreSQL database.
I must be missing something. What exactly does this accomplish that
couldn't be done at least as flexibly with a simple
Josh Berkus josh@agliodbs.com writes:
Yes, I agree with him on that. However, there's a certain amount of
confusion inspired by the organization that: If you want to look up the
table's columns go to information_schmea, if you want the table *size*
go to sysviews. But maybe that's
Andrew - Supernews wrote:
On 2006-02-27, Tom Lane [EMAIL PROTECTED] wrote:
I do have doubts about adding any large number of add-on views to
pg_catalog, because of the privileged place of that schema in search
paths. It'd be better to put them in a separate schema (pg_info
maybe?) where
Andrew,
How fine-grained do we want to get on namespaces? I'd be slightly more
inclined to have pg_info or maybe pg_utils as a place to stash not only
extra system views but other utility stuff that we want to ship but is
essentially droppable.
AFAIK, none of the contributors to newsysviews
On Mon, Feb 27, 2006 at 11:48:50AM -0500, Mark Woodward wrote:
Well, I'm sure that one could use debian's solution, but that's the
problem, it isn't PostgreSQL's solution. Shouldn't PostgreSQL provide the
mechanisms? Will debian support FreeBSD? NetBSD? Is it in the PostgreSQL
admin manual?
I
Mark,
Well, I'm sure that one could use debian's solution, but that's the
problem, it isn't PostgreSQL's solution. Shouldn't PostgreSQL provide
the mechanisms? Will debian support FreeBSD? NetBSD? Is it in the
PostgreSQL admin manual?
We are talking about a feature, like pg_service.conf,
On Mon, Feb 27, 2006 at 11:48:50AM -0500, Mark Woodward wrote:
Well, I'm sure that one could use debian's solution, but that's the
problem, it isn't PostgreSQL's solution. Shouldn't PostgreSQL provide
the
mechanisms? Will debian support FreeBSD? NetBSD? Is it in the PostgreSQL
admin manual?
On Mon, 27 Feb 2006, Tom Lane wrote:
Heikki Linnakangas [EMAIL PROTECTED] writes:
Vacuum will need to be modified to use index lookups to find index tuples
corresponding the dead heap tuples. Otherwise you have to scan through
all the indexes anyway.
This strikes me as a fairly bad idea,
On Mon, 2006-02-27 at 16:54 +, Richard Huxton wrote:
Tom Lane wrote:
Richard Huxton dev@archonet.com writes:
Subject says it all really. I've got a new client who seems to be
suffering from it, and I'm not sure if any conclusion was reached.
What's he using? 8.1 seems to have
Heikki Linnakangas [EMAIL PROTECTED] writes:
On Mon, 27 Feb 2006, Tom Lane wrote:
This strikes me as a fairly bad idea, because it makes VACUUM dependent
on correct functioning of user-written code --- consider a functional
index involving a user-written function that was claimed to be
Mark,
Well, I'm sure that one could use debian's solution, but that's the
problem, it isn't PostgreSQL's solution. Shouldn't PostgreSQL provide
the mechanisms? Will debian support FreeBSD? NetBSD? Is it in the
PostgreSQL admin manual?
We are talking about a feature, like pg_service.conf,
Maybe I'm too used to working in engineering groups. I am trying to get
input for a project. Trying to iron out what the feature set should be and
the objectives that should be attained. BEFORE I start coding.
Well that is always a good idea but:
Just saying submit a patch is the
On Mon, Feb 27, 2006 at 11:24:05AM -0800, Josh Berkus wrote:
Andrew,
How fine-grained do we want to get on namespaces? I'd be slightly more
inclined to have pg_info or maybe pg_utils as a place to stash not only
extra system views but other utility stuff that we want to ship but is
On Mon, Feb 27, 2006 at 02:17:03PM -0500, Tom Lane wrote:
Josh Berkus josh@agliodbs.com writes:
Yes, I agree with him on that. However, there's a certain amount of
confusion inspired by the organization that: If you want to look up the
table's columns go to information_schmea, if you
Mark Woodward [EMAIL PROTECTED] writes:
My frustration level often kills any desire to contribute to open source.
Sometimes, I think that open source is doomed. The various projects I
track and use are very frustrating, they remind me of dysfunctional
engineering departments in huge companies,
Greets,
[Ugh, sent one with uncompressed patch. Seems to be swallowed(No failure msg?).
Ignore it if it surfaces.]
The attached patch extends pg_am by adding two methods, scan for insert and
insert from scan. These methods are meant to provide an index user with the
ability to do conditional
James William Pye [EMAIL PROTECTED] writes:
The attached patch extends pg_am by adding two methods, scan for insert and
insert from scan. These methods are meant to provide an index user with the
ability to do conditional insertions based on the results of a conclusive
locking scan--a scan
On Mon, Feb 27, 2006 at 03:38:23PM -0500, Mark Woodward wrote:
Maybe I'm too used to working in engineering groups. I am trying to get
input for a project. Trying to iron out what the feature set should be and
the objectives that should be attained. BEFORE I start coding.
Well yes, the problem
On Mon, Feb 27, 2006 at 02:17:23PM +, Simon Riggs wrote:
Interesting point: how should EXPLAIN ANALYZE set these bits? For its
own purposes it need not request random access, but it might be
interesting to make it possible to examine both the random and nonrandom
behaviors, now that
Jim C. Nasby [EMAIL PROTECTED] writes:
On Mon, Feb 27, 2006 at 02:17:23PM +, Simon Riggs wrote:
Possibly we could make EXPLAIN ANALYZE EXECUTE set the random-access
bits.
Good point. Whichever we do will be wrong in some cases I've no real
opinion on this other than a vague
On Mon, Feb 27, 2006 at 06:01:21PM -0500, Tom Lane wrote:
Jim C. Nasby [EMAIL PROTECTED] writes:
On Mon, Feb 27, 2006 at 02:17:23PM +, Simon Riggs wrote:
Possibly we could make EXPLAIN ANALYZE EXECUTE set the random-access
bits.
Good point. Whichever we do will be wrong in some
Jim C. Nasby [EMAIL PROTECTED] writes:
On Mon, Feb 27, 2006 at 06:01:21PM -0500, Tom Lane wrote:
There is no EXPLAIN ANALYZE DECLARE, and AFAICS it would be a
contradiction in terms to have one, since DECLARE doesn't run the query.
You have no idea how glad I am that I'm not the only one who
On Mon, Feb 27, 2006 at 01:17:36PM -0500, Tom Lane wrote:
* vacuuming pages one by one as they're written by bgwriter
That's not happening. VACUUM has to be a transaction and the bgwriter
does not run transactions; nor is it in any position to clean out index
entries associated with a heap
On Mon, Feb 27, 2006 at 03:05:41PM -0500, Tom Lane wrote:
Heikki Linnakangas [EMAIL PROTECTED] writes:
On Mon, 27 Feb 2006, Tom Lane wrote:
This strikes me as a fairly bad idea, because it makes VACUUM dependent
on correct functioning of user-written code --- consider a functional
index
Just got posted to the FreeBSD list ... has several questions that revolve
around the BSD vs GPL licensing, and somewhere that 'omit' PostgreSQL as
an OS option (while others include it) ...
http://enews.sun.com/CTServlet?id=103018442-968290480:1141071714252
Marc G. Fournier
Mark,
My frustration level often kills any desire to contribute to open
source. Sometimes, I think that open source is doomed. The various
projects I track and use are very frustrating, they remind me of
dysfunctional engineering departments in huge companies, it is very hard
to positively
FYI
I have sent an email to cores to ask if I am OK to bring another but
closely related to this issue to open discussions, whose details have
already been sent to them. The reason why I'm asking is, if this issue
could be open, then the issue might be open too and that makes
discussions easier.
On Mon, Feb 27, 2006 at 05:44:20PM -0500, Tom Lane wrote:
Is this really a good idea? The fundamental problem I see with it is
that it takes away the index AM's ability to make any guarantees about
its locking behavior, ie, how long locks will be held or what other
operations might intervene
Mark Woodward wrote:
Mark,
Well, I'm sure that one could use debian's solution, but that's the
problem, it isn't PostgreSQL's solution. Shouldn't PostgreSQL provide
the mechanisms? Will debian support FreeBSD? NetBSD? Is it in the
PostgreSQL admin manual?
We are talking about a
The topic of improving vacuum for use in heavy-update environments seems
to come up frequently on the list. Has anyone weighed the costs of
allowing VACUUM to reclaim tuples that are not older than the oldest
transaction but are nonetheless invisible to all running transactions?
It seems
Mark Woodward [EMAIL PROTECTED] writes:
My frustration level often kills any desire to contribute to open
source.
Sometimes, I think that open source is doomed. The various projects I
track and use are very frustrating, they remind me of dysfunctional
engineering departments in huge
Mark Woodward wrote:
Mark,
Well, I'm sure that one could use debian's solution, but that's the
problem, it isn't PostgreSQL's solution. Shouldn't PostgreSQL provide
the mechanisms? Will debian support FreeBSD? NetBSD? Is it in the
PostgreSQL admin manual?
We are talking about a
I don't see how this is much better than just pointing to different
configuration file for each postmaster.
---
Mark Woodward wrote:
One question I have is how this feature would be an improvement over
just pointing
I could not find anything in the Frontend/Backend protocol docs about
character encoding in the StartupMessage. Assuming it is legal for a
database or user name to have unicode characters, how is this handled
when nothing yet has been said about the client encoding?
Thanks,
John DeSoi,
I could not find anything in the Frontend/Backend protocol docs about
character encoding in the StartupMessage. Assuming it is legal for a
database or user name to have unicode characters, how is this handled
when nothing yet has been said about the client encoding?
A similar badness is that
Jim C. Nasby [EMAIL PROTECTED] writes:
On Mon, Feb 27, 2006 at 03:05:41PM -0500, Tom Lane wrote:
Moreover, you haven't pointed to any strong reason to adopt this
methodology. It'd only be a win when vacuuming pretty small numbers
of tuples, which is not the design center for VACUUM, and isn't
Tom Lane [EMAIL PROTECTED] writes:
Heikki Linnakangas [EMAIL PROTECTED] writes:
* implementation of index-only scans
An index scan would not have to check the visibility information of heap
tuples on those heap pages that are marked as clean in the dead space map.
This requires that
Paul Tillotson [EMAIL PROTECTED] writes:
The topic of improving vacuum for use in heavy-update environments seems
to come up frequently on the list. Has anyone weighed the costs of
allowing VACUUM to reclaim tuples that are not older than the oldest
transaction but are nonetheless
Christopher Kings-Lynne [EMAIL PROTECTED] writes:
I could not find anything in the Frontend/Backend protocol docs about
character encoding in the StartupMessage. Assuming it is legal for a
database or user name to have unicode characters, how is this handled
when nothing yet has been said
I just tried using ipcclean in 8.1.3. It doesn't work when I su to the
pgsql user. This part of the script:
if [ $USER = 'root' -o $LOGNAME = 'root' ]
Always fails because even tho $USER is set to 'pgsql' when su'ed,
$LOGNAME is still root.
This is on FreeBSD 4.9
Chris
I don't see any very nice solution at the moment. Once we get support
for per-column locales, it might be possible to declare that the shared
catalogs are always in UTF8 encoding and get the necessary
conversions to happen automatically.
At the very least, could we always convert dbnames and
Ühel kenal päeval, E, 2006-02-27 kell 13:17, kirjutas Tom Lane:
Heikki Linnakangas [EMAIL PROTECTED] writes:
Vacuum will need to be modified to use index lookups to find index tuples
corresponding the dead heap tuples. Otherwise you have to scan through
all the indexes anyway.
This
67 matches
Mail list logo
