mlw <[EMAIL PROTECTED]> writes:
> Nathan Myers wrote:
>> But using SOMAXCONN blindly is always wrong; that is often 5, which
>> is demonstrably too small.
> It is rumored that many BSD version are limited to 5.
BSD systems tend to claim SOMAXCONN = 5 in the header files, but *not*
to have such a
Martijn van Oosterhout <[EMAIL PROTECTED]> writes:
> [ replace switch statements with function pointers ]
I've built systems both ways, and I can't say that I find any real
gain in transparency either way. I'm not excited about modifying
Postgres this way. Function pointers have some definite d
> Tatsuo Ishii writes:
>
> > I have not checked iconv seriously since it's not very portable among
> > our supported platforms.
>
> Allow me to bring you up to date:
>
> aix yes
> beos
> bsdi
> darwin
> freebsd in ports
> hpux yes
> irix5 yes
> linux
Nathan Myers wrote:
> > There are two was to think about this. Either you make this parameter
> > tunable to give a proper estimate of the usability of the system, i.e.
> > tailor the listen queue parameter to reject sockets when some number
> > of sockets are waiting, or you say no one should eve
I notice that the query executor currently has a lot of switch statements on
the the type of node it is descending to. This means you get a call tree
like:
ExecProcNode
ExecNestLoop
ExecProcNode
ExecMergeJoin
...
Wouldn't it be nicer if the Plan had access to function pointer
> * I agree with Tom's assertion that it's an awful lot of complexity for such
> a marginal gain. Look at the size of the patch and the fact that it has all
> been useless for the last few years.
>
> * I didn't send it to -patches because it's not ready yet.
>
> * Only posted a URL, not the patc
On Fri, Jul 13, 2001 at 06:34:22PM -0400, Bruce Momjian wrote:
> > Let's drop the meta-discussions and cut to the chase: given that we are
> > about to re-enable partial indexes, should we try to make EXTEND INDEX
> > work too, or just remove it?
>
> We don't let people add columns to an existing
On Fri, Jul 13, 2001 at 05:49:56PM -0400, Tom Lane wrote:
> Let's drop the meta-discussions and cut to the chase: given that we are
> about to re-enable partial indexes, should we try to make EXTEND INDEX
> work too, or just remove it?
Just a few clarifications:
* The reason it didn't go to -hac
Naomi Walker <[EMAIL PROTECTED]> writes:
> Is there any way to backtrack from an OID to tell what table included that
> row (like some secret incantation from the system tables)?
Nope, sorry. There's very little magic about OIDs at all; they're just
values from a sequence.
Is there any way to backtrack from an OID to tell what table included that
row (like some secret incantation from the system tables)?
--
Naomi Walker
Chief Information Officer
Eldorado Computing, Inc.
602-604-3100 ext 242
---(end of broadcast)--
Since I am about to add a "bulk delete" routine to the index access
method APIs for concurrent VACUUM, I need to add a column to pg_am
to define the associated procedure for each index AM. This seems like
a fine time to clean up some of the other outstanding TODO items for
pg_am:
1. Add boolean
> Let's drop the meta-discussions and cut to the chase: given that we are
> about to re-enable partial indexes, should we try to make EXTEND INDEX
> work too, or just remove it?
>
> The idea of EXTEND INDEX is to allow replacement of a partial index's
> predicate. However, the implementation onl
Let's drop the meta-discussions and cut to the chase: given that we are
about to re-enable partial indexes, should we try to make EXTEND INDEX
work too, or just remove it?
The idea of EXTEND INDEX is to allow replacement of a partial index's
predicate. However, the implementation only supports w
> > > > Note, this patch makes it as if it never existed. So, if you think some of
> > > > the code may be useful, now is the time to speak up! :)
> > > Shouldn't this conversation be happening on the -hackers list? TIA
> > Actually, because it had a patch attached, it should go to patches,
> > r
> > > > Note, this patch makes it as if it never existed. So, if you think some of
> > > > the code may be useful, now is the time to speak up! :)
> > > Shouldn't this conversation be happening on the -hackers list? TIA
> > Actually, because it had a patch attached, it should go to patches,
> > r
> > > Note, this patch makes it as if it never existed. So, if you think some of
> > > the code may be useful, now is the time to speak up! :)
> > Shouldn't this conversation be happening on the -hackers list? TIA
> Actually, because it had a patch attached, it should go to patches,
> right?
imh
> Tatsuo Ishii writes:
>
> > I have not checked iconv seriously since it's not very portable among
> > our supported platforms.
>
> Allow me to bring you up to date:
>
> aix yes
> beos
> bsdi
Count bsdi as yes. I have it working here. Compiled fine.
--
Bruce Momjian
Tatsuo Ishii writes:
> I have not checked iconv seriously since it's not very portable among
> our supported platforms.
Allow me to bring you up to date:
aix yes
beos
bsdi
darwin
freebsd in ports
hpuxyes
irix5 yes
linux yes
netbsd in
Hello,
I have a problem with rules in postgres, it may be a bug, or maybe I'm doing
something wrong. I'm running version 7.1.2 on a freebsd 4.3 box.
Here is my table:
CREATE TABLE customer (
cono integer not null,
Name varchar,
ssn varchar(10),
PRIMARY KEY (cono)
);
Here is the rule:
> Bruce Momjian writes:
>
> > Can't I keep it on the TODO until it is done? And wasn't yesterday
> > tomorrow? :-)
>
> No, tomorrow was the day after June 9th.
Are you saying you did it already? I see it in CVS now. TODO updated.
--
Bruce Momjian| http://candle
Bruce Momjian writes:
> Can't I keep it on the TODO until it is done? And wasn't yesterday
> tomorrow? :-)
No, tomorrow was the day after June 9th.
--
Peter Eisentraut [EMAIL PROTECTED] http://funkturm.homeip.net/~peter
---(end of broadcast)-
> Bruce Momjian writes:
>
> > > On Sat, 9 Jun 2001, Peter Eisentraut wrote:
> > >
> > > > Vince Vielhaber writes:
> > > >
> > > > > I can grant a series of privileges (comma separated) on a series of
> > > > > objects (comma separated) to either a user, group or public NOT a
> > > > > comma separ
> > The conventional VACUUM would then be something you do as part of a DB
> > reorganization (maybe once every month or so).
>
> Yes, but in other DB's if you UPDATE all rows in the table, you don't
> double the disk space.
Sure, but what is wrong with keeping the space allocated for the next
"P. Dwayne Miller" <[EMAIL PROTECTED]> writes:
> I think 4 seconds is way too long to return the results. And NULLs in a
> column should not change the answer.
If you're doing count(foo) then NULLs in column foo definitely *should*
change the answer. count(foo) does not count nulls.
It seemed
"P. Dwayne Miller" wrote:
>
> I think 4 seconds is way too long to return the results. And NULLs in a
> column should not change the answer. It seems logical that even a sequential
> scan of an index would be much faster than a scan of the table (in this case
> the record size is fairly large).
> > Note, this patch makes it as if it never existed. So, if you think some of
> > the code may be useful, now is the time to speak up! :)
>
> Shouldn't this conversation be happening on the -hackers list? TIA
Actually, because it had a patch attached, it should go to patches,
right?
--
Br
Nathan Myers writes:
> When the system is too heavily loaded (however measured), any further
> login attempts will fail. What I suggested is, instead of the
> postmaster accept()ing the connection, why not leave the connection
> attempt in the queue until we can afford a back end to handle it?
On Thu, Jul 12, 2001 at 12:04:25PM +0900, Tatsuo Ishii wrote:
> > Has it ever been considered to (optionally) use the iconv interface for
> > character set conversion instead of rolling our own? It seems to be a lot
> > more flexible, has pluggable conversion modules (depending on the
> > impleme
Bruce Momjian writes:
> > On Sat, 9 Jun 2001, Peter Eisentraut wrote:
> >
> > > Vince Vielhaber writes:
> > >
> > > > I can grant a series of privileges (comma separated) on a series of
> > > > objects (comma separated) to either a user, group or public NOT a
> > > > comma separated list of users
> > > The conventional VACUUM would then be something you do as part of a DB
> > > reorganization (maybe once every month or so).
> >
> > Yes, but in other DB's if you UPDATE all rows in the table, you don't
> > double the disk space.
>
> Sure, but what is wrong with keeping the space allocated f
On Fri, Jul 13, 2001 at 07:53:02AM -0400, mlw wrote:
> Zeugswetter Andreas SB wrote:
> > I liked the idea of min(MaxBackends, PG_SOMAXCONN), since there is no use in
> > accepting more than your total allowed connections concurrently.
>
> I have been following this thread and I am confused why th
> Note, this patch makes it as if it never existed. So, if you think some of
> the code may be useful, now is the time to speak up! :)
Shouldn't this conversation be happening on the -hackers list? TIA
- Thomas
---(end of broadcast)
On Fri, Jul 13, 2001 at 10:36:13AM +0200, Zeugswetter Andreas SB wrote:
>
> > When the system is too heavily loaded (however measured), any further
> > login attempts will fail. What I suggested is, instead of the
> > postmaster accept()ing the connection, why not leave the connection
> > att
>
> > I also think we have to leave VACUUM alone and come up with a new name
> > for our light VACUUM. That way, people who do VACUUM at night when no
> > one is on the system can keep doing that, and just add something to run
> > light vacuum periodically during the day.
>
> If I understood wh
I think 4 seconds is way too long to return the results. And NULLs in a
column should not change the answer. It seems logical that even a sequential
scan of an index would be much faster than a scan of the table (in this case
the record size is fairly large).
I'm trying to optimize queries that
"P. Dwayne Miller" <[EMAIL PROTECTED]> writes:
> What's the fastest way to select the number of rows in a table? If I
> use count(*) with no whereclause, it uses a seq_scan and takes 4 secs
> (122k rows). With a where clause, it uses an index and returns in < 1
> sec. Selecting count(requestnu
Zeugswetter Andreas SB wrote:
>
> > When the system is too heavily loaded (however measured), any further
> > login attempts will fail. What I suggested is, instead of the
> > postmaster accept()ing the connection, why not leave the connection
> > attempt in the queue until we can afford a back
> When the system is too heavily loaded (however measured), any further
> login attempts will fail. What I suggested is, instead of the
> postmaster accept()ing the connection, why not leave the connection
> attempt in the queue until we can afford a back end to handle it?
Because the clie
> I also think we have to leave VACUUM alone and come up with a new name
> for our light VACUUM. That way, people who do VACUUM at night when no
> one is on the system can keep doing that, and just add something to run
> light vacuum periodically during the day.
If I understood what VACUUM ligh
39 matches
Mail list logo
