Ühel kenal päeval, E, 2007-06-11 kell 22:55, kirjutas Dann Corbit:
> > -Original Message-
...
> > > I hope someone who truly understands database interfaces will read
> > > this thread and address the issue.
> > > For now we will have to "special case" postgres in our application
> > > unti
> -Original Message-
> From: Hannu Krosing [mailto:[EMAIL PROTECTED]
> Sent: Monday, June 11, 2007 10:43 PM
> To: Larry McGhaw
> Cc: Tom Lane; Alvaro Herrera; Dann Corbit; Gregory Stark; Martijn van
> Oosterhout; pgsql-hackers@postgresql.org
> Subject: Re: [HACKERS] Selecting a constant que
> -Original Message-
> From: Hannu Krosing [mailto:[EMAIL PROTECTED]
> Sent: Monday, June 11, 2007 8:42 PM
> To: Dann Corbit
> Cc: Tom Lane; Gregory Stark; pgsql-hackers@postgresql.org
> Subject: Re: [HACKERS] Selecting a constant question
>
> Ühel kenal päeval, E, 2007-06-11 kell 13:38, k
Ühel kenal päeval, E, 2007-06-11 kell 22:11, kirjutas Larry McGhaw:
> As far as I am aware these statements are true. If you have a
> specific example you could provide to the contrary that would be
> interesting.
>
> Even if there are such conditions it does not change the fact that
> libpq and
Ühel kenal päeval, E, 2007-06-11 kell 13:38, kirjutas Dann Corbit:
> > -Original Message-
> > From: Tom Lane [mailto:[EMAIL PROTECTED]
> > Sent: Monday, June 11, 2007 1:32 PM
> > To: Dann Corbit
> > Cc: Gregory Stark; pgsql-hackers@postgresql.org
> > Subject: Re: [HACKERS] Selecting a const
As far as I am aware these statements are true. If you have a specific example
you could provide to the contrary that would be interesting.
Even if there are such conditions it does not change the fact that libpq and/or
postgresql is deficient in this area.
For any query, the database should
Andrew Dunstan wrote:
>
> The CSVlog pipe is a separate pipe from the stderr pipe. Anything that
> goes to stderr now will continue to go to stderr, wherever that is.
>
> I like this scheme for a couple of reasons:
> . it will include the ability to tell the real end of a message
> . it will let u
> -Original Message-
> From: Tom Lane [mailto:[EMAIL PROTECTED]
> Sent: Monday, June 11, 2007 3:35 PM
> To: Dann Corbit
> Cc: Gregory Stark; Martijn van Oosterhout;
pgsql-hackers@postgresql.org;
> Larry McGhaw
> Subject: Re: [HACKERS] Selecting a constant question
>
> "Dann Corbit" <[EMAIL
> -Original Message-
> From: Tom Lane [mailto:[EMAIL PROTECTED]
> Sent: Monday, June 11, 2007 5:32 PM
> To: Larry McGhaw
> Cc: Alvaro Herrera; Dann Corbit; Gregory Stark; Martijn van
Oosterhout;
> pgsql-hackers@postgresql.org
> Subject: Re: [HACKERS] Selecting a constant question
>
> "Larr
> -Original Message-
> From: Tom Lane [mailto:[EMAIL PROTECTED]
> Sent: Monday, June 11, 2007 5:12 PM
> To: Dann Corbit
> Cc: pgsql-hackers@postgresql.org; Larry McGhaw
> Subject: Re: [HACKERS] Got no response last time on setsockopt post,
so I
> thought I would reiterate.
>
> "Dann Corbit
"Larry McGhaw" <[EMAIL PROTECTED]> writes:
> I think perhaps we have lost sight of the main issue:
> 1) libpq can properly describe the maximum internal data size of any
> numeric or char column in a table via Pqfsize
> 2) libpq can properly describe the maximum internal data size of any
> varchar
> -Original Message-
> From: [EMAIL PROTECTED] [mailto:pgsql-hackers-
> [EMAIL PROTECTED] On Behalf Of Andrew Dunstan
> Sent: Monday, June 11, 2007 5:12 PM
> To: Larry McGhaw
> Cc: pgsql-hackers@postgresql.org
> Subject: Re: [HACKERS] Selecting a constant question
>
>
>
> Larry McGhaw wr
"Dann Corbit" <[EMAIL PROTECTED]> writes:
> May I suggest:
> http://www-didc.lbl.gov/TCP-tuning/setsockopt.html
> http://www.ncsa.uiuc.edu/People/vwelch/net_perf/tcp_windows.html
I poked around on those pages and almost immediately came across
http://www.psc.edu/networking/projects/tcptune/
which
Larry McGhaw wrote:
4) libpq **cannot** describe the maximum internal data size of a char or
varchar constant!
Example: select '123' from
This is clearly a bug or serious oversight in libpq that should be
addressed.
The database *knows* this size of the char constant (obviously), and
should
> -Original Message-
> From: [EMAIL PROTECTED] [mailto:pgsql-hackers-
> [EMAIL PROTECTED] On Behalf Of Kris Jurka
> Sent: Monday, June 11, 2007 5:04 PM
> To: Larry McGhaw
> Cc: pgsql-hackers@postgresql.org
> Subject: Re: [HACKERS] Selecting a constant question
>
>
>
> On Mon, 11 Jun 2007
On Mon, 11 Jun 2007, Larry McGhaw wrote:
I think perhaps we have lost sight of the main issue:
2) libpq can properly describe the maximum internal data size of any
varchar column via Pqfmod
SELECT cola || colb FROM tab;
3) libpq can properly describe the maximum internal data size of any
I think perhaps we have lost sight of the main issue:
1) libpq can properly describe the maximum internal data size of any
numeric or char column in a table via Pqfsize
2) libpq can properly describe the maximum internal data size of any
varchar column via Pqfmod
3) libpq can properly describe the
I think perhaps we have lost sight of the main issue:
1) libpq can properly describe the maximum internal data size of any
numeric or char column in a table via Pqfsize
2) libpq can properly describe the maximum internal data size of any
varchar column via Pqfmod
3) libpq can properly describe the
> -Original Message-
> From: Andrew Dunstan [mailto:[EMAIL PROTECTED]
> Sent: Monday, June 11, 2007 4:35 PM
> To: Dann Corbit
> Cc: Tom Lane; pgsql-hackers@postgresql.org; Larry McGhaw
> Subject: Re: [HACKERS] Got no response last time on setsockopt post,
so I
> thought I would reiterate.
>
Dann Corbit wrote:
However, I won't twist your arm. I just wanted to be sure that those at
the PostgreSQL organization were aware of this simple trick. Our
products run on:
Aix
BeOS
Hpux
Linux (everywhere, including mainframe zLinux)
MVS
SunOS
Solaris
OpenVMS Alpha
OpenVMS VAX
OpenVMS Itanium
> -Original Message-
> From: Greg Smith [mailto:[EMAIL PROTECTED]
> Sent: Monday, June 11, 2007 4:09 PM
> To: Dann Corbit
> Cc: pgsql-hackers@postgresql.org
> Subject: Re: [HACKERS] Got no response last time on setsockopt post,
so I
> thought I would reiterate.
>
> On Mon, 11 Jun 2007, Dan
On Mon, 11 Jun 2007, Dann Corbit wrote:
These two calls make our remote queries via libpq about twice as fast on
average.
Can you comment a bit on what your remote queries are typically doing?
You'll need to provide at least an idea what type of test case you're
seeing the improvement on for
> -Original Message-
> From: Tom Lane [mailto:[EMAIL PROTECTED]
> Sent: Monday, June 11, 2007 3:50 PM
> To: Dann Corbit
> Cc: Martijn van Oosterhout; Alvaro Herrera; Gregory Stark; pgsql-
> [EMAIL PROTECTED]; Larry McGhaw
> Subject: Re: [HACKERS] Selecting a constant question
>
> "Dann Cor
> -Original Message-
> From: Alvaro Herrera [mailto:[EMAIL PROTECTED]
> Sent: Monday, June 11, 2007 3:44 PM
> To: Dann Corbit
> Cc: Tom Lane; Gregory Stark; Martijn van Oosterhout; pgsql-
> [EMAIL PROTECTED]; Larry McGhaw
> Subject: Re: [HACKERS] Selecting a constant question
>
> Dann Corb
> -Original Message-
> From: Tom Lane [mailto:[EMAIL PROTECTED]
> Sent: Monday, June 11, 2007 3:41 PM
> To: Dann Corbit
> Cc: pgsql-hackers@postgresql.org; Larry McGhaw
> Subject: Re: [HACKERS] Got no response last time on setsockopt post,
so I
> thought I would reiterate.
>
> "Dann Corbit
"Dann Corbit" <[EMAIL PROTECTED]> writes:
>> To be honest, the concept that a widget requires a constant that can't
>> be changed later is also a bit odd.
> Not when the data itself is a constant that cannot be changed.
Surely this case is not sufficiently important to justify designing
your enti
Dann Corbit wrote:
> If the server bound the data as UNICODE, then it will tell me
> UNICODE(3). I know how big this will be.
>
> In the worst case scenario it will fit in 3*4 = 12 bytes.
>
> If the server is built without UNICODE enabled, then it will definitely
> fit in 3 bytes.
Unless it's
"Dann Corbit" <[EMAIL PROTECTED]> writes:
> These two calls make our remote queries via libpq about twice as fast on
> average.
And, perhaps, cause even greater factors of degradation in other
scenarios (not to mention the possibility of complete failure on some
platforms). You haven't provided n
> -Original Message-
> From: Martijn van Oosterhout [mailto:[EMAIL PROTECTED]
> Sent: Monday, June 11, 2007 3:29 PM
> To: Dann Corbit
> Cc: Alvaro Herrera; Gregory Stark; pgsql-hackers@postgresql.org; Larry
> McGhaw
> Subject: Re: [HACKERS] Selecting a constant question
>
> On Mon, Jun 11,
Dann Corbit wrote:
I have a PostgreSQL feature request:
Report the maximum size of a variable length string from the server.
Surely, we cannot be the only people who will need this information. If
(for example) someone wants to bind to a grid, then the maximum size has
to be known in advance
"Dann Corbit" <[EMAIL PROTECTED]> writes:
> Giving me the information about the data type will be enough. As an
> example, in this case we have varchar data. If the server should be so
> kind as to report varchar(1) for '1' or varchar(3) for '123' then I
> would not have any difficulty binding th
On Mon, Jun 11, 2007 at 03:18:33PM -0700, Dann Corbit wrote:
> Sure, but when I bind to a grid, I need to know a-priori how big the
> biggest returned instance can be. Reading the entire data set twice to
> learn the size of a constant seems rather conceptually odd to me.
To be honest, the concep
Dann Corbit wrote:
> > Oh, you have the length information for each datum all right. It's on
> > the first four bytes of it.
>
> Sure, but when I bind to a grid, I need to know a-priori how big the
> biggest returned instance can be. Reading the entire data set twice to
> learn the size of a co
> -Original Message-
> From: Alvaro Herrera [mailto:[EMAIL PROTECTED]
> Sent: Monday, June 11, 2007 3:16 PM
> To: Dann Corbit
> Cc: Gregory Stark; Martijn van Oosterhout;
pgsql-hackers@postgresql.org;
> Larry McGhaw
> Subject: Re: [HACKERS] Selecting a constant question
>
> Dann Corbit wro
These two calls make our remote queries via libpq about twice as fast on
average. It seems to me like it might be a nice addition to the core
product's libpq (I poked it into the spot where the Nagle algorithm is
turned off, but another place would be fine too). Can anyone give me a
reason why it
Dann Corbit wrote:
> > "Dann Corbit" <[EMAIL PROTECTED]> writes:
> >
> > In fact psql needs it and implements this. It has to skim through the
> > entire
> > result set to calculate the column widths. It's quite a lot of work
> but
> > the
> > server is in no better position to do it than psql.
>
> -Original Message-
> From: Gregory Stark [mailto:[EMAIL PROTECTED]
> Sent: Monday, June 11, 2007 2:41 PM
> To: Dann Corbit
> Cc: Martijn van Oosterhout; pgsql-hackers@postgresql.org; Larry McGhaw
> Subject: Re: [HACKERS] Selecting a constant question
>
> "Dann Corbit" <[EMAIL PROTECTED]>
"Dann Corbit" <[EMAIL PROTECTED]> writes:
> Surely, we cannot be the only people who will need this information. If
> (for example) someone wants to bind to a grid, then the maximum size has
> to be known in advance.
In fact psql needs it and implements this. It has to skim through the entire
re
> -Original Message-
> From: [EMAIL PROTECTED] [mailto:pgsql-hackers-
> [EMAIL PROTECTED] On Behalf Of Dann Corbit
> Sent: Monday, June 11, 2007 1:52 PM
> To: Martijn van Oosterhout
> Cc: pgsql-hackers@postgresql.org
> Subject: Re: [HACKERS] Selecting a constant question
>
> > -Origina
> -Original Message-
> From: Martijn van Oosterhout [mailto:[EMAIL PROTECTED]
> Sent: Monday, June 11, 2007 1:46 PM
> To: Dann Corbit
> Subject: Re: [HACKERS] Selecting a constant question
>
> On Mon, Jun 11, 2007 at 01:29:37PM -0700, Dann Corbit wrote:
> > Our application is using the lib
"Tom Lane" <[EMAIL PROTECTED]> writes:
> Trying the example in psql seems to be about the same speed both ways, with
> if anything a slight advantage to select '1'.
Fwiw I see a slight advantage for '1' as well. I wonder why.
--
Gregory Stark
EnterpriseDB http://www.enterprisedb.co
> -Original Message-
> From: Tom Lane [mailto:[EMAIL PROTECTED]
> Sent: Monday, June 11, 2007 1:32 PM
> To: Dann Corbit
> Cc: Gregory Stark; pgsql-hackers@postgresql.org
> Subject: Re: [HACKERS] Selecting a constant question
>
> "Dann Corbit" <[EMAIL PROTECTED]> writes:
> > The issue is th
"Dann Corbit" <[EMAIL PROTECTED]> writes:
> The issue is this:
> Postgres describes the column with a typmod of -1 (unknown) and a length
> of 65534.
Oh, you're looking at typlen not typmod. Please observe the comments in
pg_type.h:
/*
* For a fixed-size type, typlen is the numb
On Mon, Jun 11, 2007 at 12:55:55PM -0700, Dann Corbit wrote:
> The issue is this:
>
> Postgres describes the column with a typmod of -1 (unknown) and a length
> of 65534.
Postgres does no such thing. How can it possibly know the maximum size
of a column before executing the query?
Have a nice da
> -Original Message-
> From: Gregory Stark [mailto:[EMAIL PROTECTED]
> Sent: Monday, June 11, 2007 12:48 PM
> To: Dann Corbit
> Cc: pgsql-hackers@postgresql.org
> Subject: Re: [HACKERS] Selecting a constant question
>
> "Dann Corbit" <[EMAIL PROTECTED]> writes:
>
> > SELECT 1 FROM test.d
"Dann Corbit" <[EMAIL PROTECTED]> writes:
> SELECT 1 FROM test.dbo.a_003
>
> gets about 60,000 records per second
>
> SELECT '1' FROM test.dbo.a_003
>
> gets about 600 records per second.
>
> The cause is that postgres describes the return column as "unknown"
> length 65534 in the 2nd case.
W
"Dann Corbit" <[EMAIL PROTECTED]> writes:
> SELECT 1 FROM test.dbo.a_003
> gets about 60,000 records per second
> SELECT '1' FROM test.dbo.a_003
> gets about 600 records per second.
> The cause is that postgres describes the return column as "unknown"
> length 65534 in the 2nd case.
Postgres de
SELECT 1 FROM test.dbo.a_003
gets about 60,000 records per second
SELECT '1' FROM test.dbo.a_003
gets about 600 records per second.
The cause is that postgres describes the return column as "unknown"
length 65534 in the 2nd case.
Since the value is a constant, it seems rathe
Joshua D. Drake wrote:
Take the following:
INFO: analyzing "pg_catalog.pg_authid"
INFO: "pg_authid": scanned 1 of 1 pages, containing 5 live rows and 0
dead rows; 5 rows in sample, 5 estimated total rows
The above is completely redundant. Why not just say:
INFO: "pg_authid": scanned 1 of
Hello,
It is past feature freeze which means we can't introduce new features.
It is possible to submit a patch for slightly different logging output?
Take the following:
INFO: analyzing "pg_catalog.pg_authid"
INFO: "pg_authid": scanned 1 of 1 pages, containing 5 live rows and 0
dead rows;
Hi!
Still working on the ecpg-regression-tests-on-msvc. Update to follow
later today I hope. But for now:
I get the following error when trying to build the sql/parser.pgc test:
c:\prog\pgbin\pgsql\bin\ecpg --regression -o parser.c parser.pgc
parser.pgc:26: ERROR: syntax error at or near
Andrew Dunstan <[EMAIL PROTECTED]> writes:
> I'll try to get a patch out for just the stderr case, which should be
> back-patchable, then adjust the CSVlog patch to use it.
Sounds like a plan.
> I'm thinking of handling the partial lines with a small dynahash of
> StringInfo buffers, which get
Magnus Hagander wrote:
On Mon, Jun 11, 2007 at 10:23:06AM -0400, Andrew Dunstan wrote:
Tom Lane wrote:
Every so often, buildfarm member skylark reports a "StartDb:2" failure,
as for instance here:
http://www.pgbuildfarm.org/cgi-bin/show_log.pl?nm=skylark&dt=2007-06-10%2023:00:01
but t
Tom Lane wrote:
Alvaro Herrera <[EMAIL PROTECTED]> writes:
The idea of one pipe per process is not really workable, because it
would mean having as many pipes as backends which does not sound very
good. But how about a mixed approach -- like have the all the backends
share a pipe, controll
On Mon, Jun 11, 2007 at 10:23:06AM -0400, Andrew Dunstan wrote:
>
>
> Tom Lane wrote:
> >Every so often, buildfarm member skylark reports a "StartDb:2" failure,
> >as for instance here:
> >http://www.pgbuildfarm.org/cgi-bin/show_log.pl?nm=skylark&dt=2007-06-10%2023:00:01
> >but the logs contain n
Tom Lane wrote:
Every so often, buildfarm member skylark reports a "StartDb:2" failure,
as for instance here:
http://www.pgbuildfarm.org/cgi-bin/show_log.pl?nm=skylark&dt=2007-06-10%2023:00:01
but the logs contain no trace of any actual failure. What's happening,
and why is the buildfarm faili
Heikki Linnakangas wrote:
Tom Lane wrote:
Heikki Linnakangas <[EMAIL PROTECTED]> writes:
I tried to repeat the DBT-2 runs with the "oldestxmin refresh" patch,
but to my surprise the baseline run with CVS head, without the patch,
behaved very differently than it did back in March.
I rerun the
On Mon, Jun 11, 2007 at 10:03:57AM +0200, Magnus Hagander wrote:
> If you find the other behaviour useful, perhaps add a commandline switch
> that makes it leave the file around? Just make the
> remove-the-file-on-failure default.
Should be fixed now. I don't think such a command line switch is ne
* Zeugswetter Andreas ADI SD ([EMAIL PROTECTED]) wrote:
>
> > > Wouldn't it be far more logical to decide that if a user has the
> > > permissions to do a DELETE FROM table; then they have permission to
> do
> > > a TRUNCATE? Why make an additional permission?
> >
> > Truncate doesn't fire ON D
Hi,
I can probably figure it out on linux but I would like to do a one
click install based upon defined defaults for the Postgresql database
(creating it as a service and load my sql file which creates the
database) - has anyone written such a how to?
thanks
Tim
---(end
> > Wouldn't it be far more logical to decide that if a user has the
> > permissions to do a DELETE FROM table; then they have permission to
do
> > a TRUNCATE? Why make an additional permission?
>
> Truncate doesn't fire ON DELETE triggers.
Yes, but it would imho be ok if there are'nt any on d
Hi Simon,
I'll be glad to test it for you when you're ready!
Thanks for looking at this issue.
Best regards,
On Sun, 10 Jun 2007, Simon Riggs wrote:
> Date: Sun, 10 Jun 2007 23:55:32 +0100
> From: Simon Riggs <[EMAIL PROTECTED]>
> To: [EMAIL PROTECTED]
> Cc: pgsql-hackers list
> Subject: Re: [H
ITAGAKI Takahiro wrote:
Heikki Linnakangas <[EMAIL PROTECTED]> wrote:
True. On the other hand, if we issue writes in essentially random order,
we might fill the kernel buffers with random blocks and the kernel needs
to flush them to disk as almost random I/O. If we did the writes in
groups, t
Martijn van Oosterhout wrote:
On Mon, Jun 11, 2007 at 09:40:08AM +0200, Ewald Geschwinde wrote:
My problem is that some users don't have access to change the structure but
they wanted to delete all data from the table
they try truncate - does not work because not the owner
so they make a delete
On Mon, Jun 11, 2007 at 09:40:08AM +0200, Ewald Geschwinde wrote:
> My problem is that some users don't have access to change the structure but
> they wanted to delete all data from the table
> they try truncate - does not work because not the owner
> so they make a delete from a really big table
Hello,
Updatable cursors can be supported in PL/pgSQL.
Explicit PL/pgSQL cursors are named, then we need only skip CURRENT OF
clause in parsing of SQL statements.
Regards
Pavel Stehule
---(end of broadcast)---
TIP 6: explain analyze is your frien
On Mon, Jun 11, 2007 at 08:05:16AM +0200, Michael Meskes wrote:
> On Sun, Jun 10, 2007 at 09:56:44PM +0200, Magnus Hagander wrote:
> > AFAIK, most other compilers delete their output if it's not valid. Is
> > there any particular reason why ecpg doesn't do this?
>
> No, not really. Sometimes it co
On Mon, 11 Jun 2007, ITAGAKI Takahiro wrote:
If the kernel can treat sequential writes better than random writes, is
it worth sorting dirty buffers in block order per file at the start of
checkpoints?
I think it has the potential to improve things. There are three obvious
and one subtle arg
On Mon, 4 Jun 2007, Kris Jurka wrote:
On Mon, 4 Jun 2007, Andrew Dunstan wrote:
turnip_moth is also a Solaris 9 box and doesn't seem have the same issue.
Kris, is there anything unusual installed on the box that would make it
behave like this?
Not sure what's going on here. I did a ma
Yes, there is a use-case for it. If you don't have triggers or
transactional concerns on the table and you want users to be able to
truncate tables while not allowing them to do things like change the
table structure. I proposed a patch a while ago to implement a seperate
permission for truncate
70 matches
Mail list logo
