Ü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.
>
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 s
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
-
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 be
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 inv
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 r
"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,
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 i
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, Ph
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
> 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?
>> >>
> "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
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 that
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
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 interve
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.
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 positive
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
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
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
"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
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
"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
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
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 probl
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
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
"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 com
On Mon, Feb 27, 2006 at 02:17:03PM -0500, Tom Lane wrote:
> Josh Berkus 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 tabl
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
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 antith
> 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_
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
On Mon, 2006-02-27 at 16:54 +, Richard Huxton wrote:
> Tom Lane wrote:
> > Richard Huxton 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 alleviat
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, be
> 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
>> ad
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.c
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 manua
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
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?) whe
Josh Berkus 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 unavoidable. Or ma
Thank you for a quick response.
From: "Tom Lane"
> > C:\Program Files\PostgreSQL\8.1\bin>pqpasswd.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
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.
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
"Hiroshi Saito" <[EMAIL PROTECTED]> writes:
> C:\Program Files\PostgreSQL\8.1\bin>pqpasswd.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 edi
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
On Mon, Feb 27, 2006 at 11:39:30AM -0500, Tom Lane wrote:
| Josh Berkus 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
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 variab
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 de
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
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 b
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:
* spee
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 wi
Tom Lane wrote:
Richard Huxton 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 or
something.
Richard Huxton 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 broadcast)---
Tom Lane wrote:
Richard Huxton 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
Richard Huxton 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 away entirely,
b
Josh Berkus 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 information_schema (li
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
> -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
> 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, pl
Yeah it really was :-) BTW I have 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 m
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
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 w
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
> 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
>> imple
"Josh Berkus" 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
> regular,
67 matches
Mail list logo
