Hi Andrew,
> Right. There's a simple pipeline way to get rid of it:
> psql -t -f query.sql | sed -e '$d' > query.out
Hi Scott,
> Tired of those blank lines in your text files? Grep them away:
> psql -tf query.sql mydatabase | grep -v "^$" > query.out
Thank you Both.
Regards,
Tena Sakai
tsa
On Thu, Apr 2, 2009 at 3:33 PM, Tena Sakai wrote:
> Hi Everybody,
>
> I am using postgres 8.3.4 on linux.
> I often use a line like:
> psql -tf query.sql mydatabase > query.out
>
> -t option gets rid of the heading and count
> report at the bottom. There is a blank line
> at the bottom, however
Hi Tom,
I am a bit surprised to hear that that '\n'
is there unconditionally. But I am sure
there are more pressing things for you to
work on. It's something I can live with.
Regards,
Tena Sakai
tsa...@gallo.ucsf.edu
-Original Message-
From: Tom Lane [mailto:t...@sss.pgh.pa.us]
Sent:
On Thursday 02 April 2009 4:22:06 pm Peter Willis wrote:
> Adrian Klaver wrote:
> > Did you happen to catch this:
> > Note that functions using RETURN NEXT or RETURN QUERY must be called as a
> > table source in a FROM clause
> >
> > Try:
> > select * from test_function(1)
>
> I did miss that, but
Adrian Klaver wrote:
Did you happen to catch this:
Note that functions using RETURN NEXT or RETURN QUERY must be called as a table
source in a FROM clause
Try:
select * from test_function(1)
I did miss that, but using that method to query the function
didn't work either. Postgres doesn't s
"Tena Sakai" writes:
> I often use a line like:
> psql -tf query.sql mydatabase > query.out
> -t option gets rid of the heading and count
> report at the bottom. There is a blank line
> at the bottom, however. Is there any way to
> have psql not give me that blank line?
Doesn't look like it
- "Peter Willis" wrote:
> Adrian Klaver wrote:
> > On Wednesday 01 April 2009 4:31:20 pm Peter Willis wrote:
> >> Hello,
> >>
> >> I am having a problem with a FUNCTION.
> >> The function creates just fine with no errors.
> >>
> >> However, when I call the function postgres produces an err
Hi Everybody,
I am using postgres 8.3.4 on linux.
I often use a line like:
psql -tf query.sql mydatabase > query.out
-t option gets rid of the heading and count
report at the bottom. There is a blank line
at the bottom, however. Is there any way to
have psql not give me that blank line?
Than
-BEGIN PGP SIGNED MESSAGE-
Hash: RIPEMD160
> I was looking to speed up a count(*) query
A few things spring to mind:
1) Use a separate table, rather than storing things inside of
dataset itself. This will reduce the activity on the dataset table.
2) Do you really need bigint for the c
On 04/02/2009 03:32 PM, Tom Lane wrote:
Tony Cebzanov writes:
What I want to do is update the assoc_count field in the dataset table
to reflect the count of related records in the assoc field. To do so, I
added the following trigger:
CREATE OR REPLACE FUNCTIO
Tony Cebzanov writes:
> What I want to do is update the assoc_count field in the dataset table
> to reflect the count of related records in the assoc field. To do so, I
> added the following trigger:
> CREATE OR REPLACE FUNCTION update_assoc_count_insert()
> RETURNS TRIGGER AS
> '
> BEGIN
>
Hi Craig, thanks for your help.
Craig Ringer wrote:
> MVCC bloat from the constant updates to the assoc_count table, maybe?
That's what a coworker suggested might be happening. The fact that a
no-op trigger performs fine but the UPDATE trigger doesn't would seem to
confirm that it's something in
Tony Cebzanov wrote:
> The throughput of the first batch of 1,000 is diminished, but still
> tolerable, but after 10,000 inserts, it's gotten much worse. This
> pattern continues, to the point where performance is unacceptable after
> 20k or 30k inserts.
>
> To rule out the performance of the tr
Adrian Klaver wrote:
On Wednesday 01 April 2009 4:31:20 pm Peter Willis wrote:
Hello,
I am having a problem with a FUNCTION.
The function creates just fine with no errors.
However, when I call the function postgres produces an error.
Perhaps someone can enlighten me.
--I can reproduce the e
Emi Lu writes:
> With ibatis, do overlap checking:
> (1) select (DATE #begin_date#, DATE #end_date#) overlaps
> (DATE '2008-01-01', DATE '2009-01-01')
> . #begin_date# is varchar
> . #end_date# is varchar
> Cause: java.sql.SQLException: ERROR: syntax error at or near "$4"
> However, when I up
Alvaro Herrera writes:
> Another way to phrase the WHERE clause is with the OVERLAPS operator,
> something like this:
> WHERE (start_ts, end_ts) OVERLAPS ('2008-12-07 07:59:59', '2008-12-07
> 08:59:59')
> What I'm not so sure about is how optimizable this construct is.
Not at all :-( --- or a
I was looking to speed up a count(*) query, as per the recommendations
on the postgres wiki:
http://wiki.postgresql.org/wiki/Slow_Counting
I decided to use the trigger approach to get an accurate count that
doesn't depend on VACUUM being run recently. I've got it working, but
the addition of the
Good morning,
With ibatis, do overlap checking:
(1) select (DATE #begin_date#, DATE #end_date#) overlaps
(DATE '2008-01-01', DATE '2009-01-01')
. #begin_date# is varchar
. #end_date# is varchar
Always get:
Cause: java.sql.SQLException: ERROR: syntax error at or near "$4"
Howeve
James Kitambara wrote:
> Dear Srikanth,
> You can solve your problem by doing this
>
> THE SQL IS AS FOLLOWS
> ASSUME TIME INTERVAL 2008-12-07 07:59:59 TO 2008-12-07 08:58:59 AND THE
> TABLE NAME time_interval
>
> COUNT (*) FROM
> (select customer_id, log_session_id, start_ts, end_ts ,
Dear Srikanth,
You can solve your problem by doing this
THE SQL IS AS FOLLOWS
ASSUME TIME INTERVAL 2008-12-07 07:59:59 TO 2008-12-07 08:58:59 AND THE TABLE
NAME time_interval
COUNT (*) FROM
(select customer_id, log_session_id, start_ts, end_ts , end_ts-start_ts as
"Interval" from time_
20 matches
Mail list logo
