On 18 October 2011 09:57, jozsef.kur...@invitel.hu wrote:
Hi,
Thanks for the reply!
But I don't want to check if the table exists, I want to see the
result of the SELECT query, if a row presence or not.
So you want to check that the table contains data? In that case it
makes no sense to
On 18 October 2011 14:11, salah jubeh s_ju...@yahoo.com wrote:
Hello,
I have many SQL script files to update schema, delete data, unit test
etc. I want to run all the files in one transaction using shell script
to ease the installation procedure. I can do that from the psql client by
that translates those values.
Alban Hertroys
--
If you can't see the forest for the trees,
cut the trees and you'll see there is no forest.
--
Sent via pgsql-general mailing list (pgsql-general@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-general
On 17 October 2011 15:20, Merlin Moncure mmonc...@gmail.com wrote:
A better way to do this is to query information_schema:
PERFORM 1 FROM information_schema.tables where schema_name = x and
table_name = y;
IF FOUND THEN
CREATE TABLE ...
END IF;
(there is a race condition in the above
On 17 October 2011 16:24, Merlin Moncure mmonc...@gmail.com wrote:
On Mon, Oct 17, 2011 at 8:44 AM, Alban Hertroys haram...@gmail.com wrote:
On 17 October 2011 15:20, Merlin Moncure mmonc...@gmail.com wrote:
A better way to do this is to query information_schema:
PERFORM 1 FROM
On 17 October 2011 17:25, Steve Crawford scrawf...@pinpointresearch.com wrote:
On 10/16/2011 04:39 PM, Scott Marlowe wrote:
On Sun, Oct 16, 2011 at 5:24 PM, Tom Lanet...@sss.pgh.pa.us wrote:
Scott Marlowescott.marl...@gmail.com writes:
On Sat, Oct 15, 2011 at 2:20 PM, Thomas
table)? In that case, try UNION ALL instead of UNION.
If you do need unique results, then you could create an index on the
combination of all those fields. That should take out the need for those
sequential scans.
Alban Hertroys
--
The scale of a problem often equals the size of an ego
not
installed.
If the database wasn't installed on a local file-system, check that the remote
file-system is functioning properly and doesn't cache an old state or something
similarly silly.
Postgres doesn't remove any dll's, so it's some external factor at play here.
Alban Hertroys
--
Screwing up
On 14 Oct 2011, at 13:58, Alexander Farber wrote:
Hi Alban and others -
On Fri, Oct 14, 2011 at 1:34 PM, Alban Hertroys haram...@gmail.com wrote:
Anyway, I think you get the sequential scans because the UNION requires to
sort all the data from both tables to guarantee that the results
On 13 October 2011 14:20, Ivan Voras ivo...@freebsd.org wrote:
Hello,
I have a table with a large number of records (millions), on which the
following should be performed:
1. Retrieve a set of records by a SELECT query with a WHERE condition
2. Process these in the application
-+-
4380103 | 4380104
(1 row)
Alban Hertroys
--
If you can't see the forest for the trees,
cut the trees and you'll see there is no forest.
--
Sent via pgsql-general mailing list (pgsql-general@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql
On 11 October 2011 16:06, Eric Radman ericsh...@eradman.com wrote:
When writing unit tests it's sometimes useful to stub functions such as
the current date and time
Is it possible to declare a global variable that can be referenced from
the user-defined function _now()? I'm looking for a
On 11 October 2011 15:41, Tom Lane t...@sss.pgh.pa.us wrote:
Alban Hertroys haram...@gmail.com writes:
On 11 Oct 2011, at 2:55, Harvey, Allan AC wrote:
My simple understanding of trunc() and casting to an integer says that
there is a bug here.
Which the type-cast should round to 4380103
On 10 October 2011 10:30, AI Rumman rumman...@gmail.com wrote:
I have an application which query on the pg_shadow view. But the user that I
was provided by my hosting server does have permission to do that.
I checked that only superuser can query in pg_shadow view. But hosting
service provider
On 6 October 2011 11:04, Adarsh Sharma adarsh.sha...@orkash.com wrote:
Dear all,
Any update on the issue.
Apparently, pg-migrator (later called pg_upgrade) is available for pg
8.3, see here for instructions:
http://www.depesz.com/index.php/2010/05/19/waiting-for-9-0-pg_upgrade/
--
If you
On 6 October 2011 12:18, Adarsh Sharma adarsh.sha...@orkash.com wrote:
We can upgrade to new version if our previous version is running.
But isn't upgrading exactly what you're trying to do? And why do you
think you need to have the old database running to be able to upgrade?
According to the
On 3 October 2011 08:33, Alexander Pyhalov a...@rsu.ru wrote:
Now we want to select count of all employees who doesn't have any
subordinates (query 1):
SELECT count(employee_id) from employees o where not exists (select 1 from
employees where manager_id=o.employee_id);
count
---
say
I have been creating casts so far, so I'm guessing a bit here.
If you create a cast WITH function, does that work?
Alban Hertroys
--
Screwing up is an excellent way to attach something to the ceiling.
--
Sent via pgsql-general mailing list (pgsql-general@postgresql.org)
To make changes
On 30 September 2011 11:20, J.V. jvsr...@gmail.com wrote:
For tables that already exist and have a foreign key relationship, is there
an equivalent alter statement for the statement below?
Does this mean that if table xxx.id primary key value changes, the foreign
key value will change as
On 29 September 2011 13:12, Radosław Smogura rsmog...@softperience.eu wrote:
sending ~1GB bytea values is borderline crazy, and is completely crazy
if you are not absolutely sure the transmission is not 100% binary. I
don't know if the JDBC sends/receives bytea as binary, but it may not.
If
On 28 September 2011 13:19, salah jubeh s_ju...@yahoo.com wrote:
Hello,
I have two views both contain identical column names , order and types
except the primary keys. I want to match these two views - return the pk
pair of the rows which match from these views - by comparing all the
You forgot to include the list ;)
On 26 Sep 2011, at 6:06, haman...@t-online.de wrote:
Alban Hertroys wrote:
To me it sounds a little bit like you're comparing every item in a =
warehouse to a set of descriptions to see what type of item it is, which =
is something you would be much better
On 26 September 2011 17:15, Edson Carlos Ericksson Richter
rich...@simkorp.com.br wrote:
Just discovered, I can’t use GIST over character varying...
Why do you think that?
--
If you can't see the forest for the trees,
Cut the trees and you'll see there is no forest.
--
Sent via pgsql-general
will hold
about 2-3 billion records with two foreign key values and a truth value each.
Alban Hertroys
--
The scale of a problem often equals the size of an ego.
--
Sent via pgsql-general mailing list (pgsql-general@postgresql.org)
To make changes to your subscription:
http
.
Alban Hertroys
--
The scale of a problem often equals the size of an ego.
--
Sent via pgsql-general mailing list (pgsql-general@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-general
On 23 September 2011 11:47, Andrew Rose andrew.r...@metaswitch.com wrote:
Basic Question: In text fields, is prefix matching significantly faster
than suffix matching?
It does depend on what type of index you use. BTrees split off text strings,
from left to right, halving the number of
On 23 September 2011 09:45, haman...@t-online.de wrote:
Alban Hertroys haram...@gmail.com wrote:
What is the output of explain?
You say 'the other table', so presumably we're dealing with a foreign
key
here. Is there an index on that column?
Albe Laurenz wrote:
Is the index used
On 23 September 2011 12:31, Ingmar Brouns swi...@gmail.com wrote:
In short: if you want to get useful commentary on your problem, you
need to provide a more complete picture.
regards, tom lane
I've posted the query plans now several times to this list, but
On 23 September 2011 14:29, haman...@t-online.de wrote:
Alban Hertroys wrote:
So you're comparing a variable field value to a variable pattern - yeah,
that's going to hurt. There's no way you could index exactly that.
Perhaps there's some way you can transform the problem so that you
On 21 September 2011 17:59, haman...@t-online.de wrote:
If I try to get many items on a prefix match
select code where code ~ wantcode
things go very slow. Explain shows a nested loop, so seemingly the table is
rescanned
for every wanted item in the other table. A test run (3000 wanted
inserting rows without using the sequence?
Alban Hertroys
--
Screwing up is an excellent way to attach something to the ceiling.
--
Sent via pgsql-general mailing list (pgsql-general@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-general
On 19 September 2011 12:01, Koen Van Impe koen.vani...@belnet.be wrote:
Hello,
I'm trying to write a query that groups records by hour.
This works fine but when there are no records for a specific hour the
query does not return a result (this seems 'logic') and I'd like it to
return '0'. I
On 16 September 2011 03:31, Adrian Klaver adrian.kla...@gmail.com wrote:
This is one of those things I find spreadsheets actually useful for. Do a
COPY or
/copy, in CSV format from the table and import it into a spreadsheet. I
find the
grid layout of a spreadsheet very useful in picking out
Caused by: org.postgresql.util.PSQLException: ERROR: column docdta is of
type bytea but expression is of type oid
Hint: You will need to rewrite or cast the expression.
Looks like that table has a column of type BYTEA, while the code expects it
to be a LOB. Perhaps the easiest fix is to
(\.) there, then reading the first 4 columns would
probably succeed; they are type text from the looks of it, so '' (tab)
is a valid character for those fields, but not for the real type column after
those.
Alban Hertroys
--
The scale of a problem often equals the size of an ego
line in emacs but wraps in alpine.)
You appear to have two tabs after Depth to Water, which would be one too many.
Alban Hertroys
--
The scale of a problem often equals the size of an ego.
--
Sent via pgsql-general mailing list (pgsql-general@postgresql.org)
To make changes to your
issue and would probably push the threshold for a seqscan up
some.
Cheers,
Alban Hertroys
--
If you can't see the forest for the trees,
cut the trees and you'll see there is no forest.
--
Sent via pgsql-general mailing list (pgsql-general@postgresql.org)
To make changes to your subscription
be playing with the random_page_cost
that Ondrej suggested, and schedule a time where I can do some explain
analyzes (production server and all).
Before you do that, turn off seqscans (there's a session option for that) and
see if index scans are actually faster.
Alban Hertroys
--
If you can't see
, but that seems to make sense with the example you gave.
You probably don't want postgres to be smart with your client's time zone
settings, hence the without time zone.
Alban Hertroys
--
Screwing up is an excellent way to attach something to the ceiling.
!DSPAM:737,4e4eadd712091047328385
inner joins improve readability of queries over
implicit joins, especially when the joins get a little more complicated.
Perhaps what you find cumbersome about them is just a matter of formatting?
Alban Hertroys
--
The scale of a problem often equals the size of an ego.
!DSPAM
root nodes reference themselves or to set
their origins to NULL.
Either case has cons and pros that usually depend on how the query results are
used.
Alban Hertroys
--
If you can't see the forest for the trees,
cut the trees and you'll see there is no forest.
!DSPAM:737,4e3523b412093530528260
BEFORE the update process?
Ah of course, there is no matching row for the update that you expect to fire
the trigger, so it never gets fired (no update takes place). I hadn't realised
that from your examples.
You can't fire a trigger on non-existant data.
De : Alban Hertroys dal
On 24 Jul 2011, at 11:00, Alban Hertroys wrote:
You can't fire a trigger on non-existant data.
I just realised the above statement is a little inexact: you can't fire
row-level triggers on non-existant data.
You can still fire statement-level triggers on them, but with those you won't
have
CPU cycles.
Alban Hertroys
--
The scale of a problem often equals the size of an ego.
!DSPAM:737,4e2a8d6912091302916282!
--
Sent via pgsql-general mailing list (pgsql-general@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-general
with no line_items) into the database.
Alban Hertroys
--
The scale of a problem often equals the size of an ego.
!DSPAM:737,4e2a9c2112098024710106!
--
Sent via pgsql-general mailing list (pgsql-general@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-general
is equivalent to field1 being unique, because NULL
means unknown and therefore doesn't add anything to make the tuple more or
less unique (just mentioning this, it's an often overlooked fact).
Alban Hertroys
--
The size of a problem often equals the size of an ego.
!DSPAM:737,4e1c0e4e12097122610358
no corresponding
date in sales or vice versa. Hence, outer joins give the same result as inner
joins.
If that's not the case then we're going to need more details, such as the
definitions of the tables.
Alban Hertroys
--
Screwing up is an excellent way to attach something to the ceiling.
!DSPAM
databases depending on which master they're running on?
From a security point-of-view I'd probably require a list of accessible remote
databases per server (so that people cannot just query any database of their
choice). That could also serve the load-balancing scenario.
Alban Hertroys
--
If you
seem to
make a whole lot of sense.
Alban Hertroys
--
The size of a problem often equals the size of an ego.
!DSPAM:737,4e1c7f0c12096580658153!
--
Sent via pgsql-general mailing list (pgsql-general@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql
reference to the latest record in your INSERT-mostly
table.
The new table should probably have a UNIQUE constraint on the key field.
Alban Hertroys
--
If you can't see the forest for the trees,
cut the trees and you'll see there is no forest.
!DSPAM:737,4e12b56712091122515968!
--
Sent via pgsql
://www.postgresql.org/mailpref/pgsql-general
Alban Hertroys
--
If you can't see the forest for the trees,
cut the trees and you'll see there is no forest.
!DSPAM:737,4e133bd412094272933627!
--
Sent via pgsql-general mailing list (pgsql-general@postgresql.org)
To make changes to your subscription:
http
their status (latest or not). That means you
do two DELETE and INSERT operations every time you want to update what the
latest row is.
That's hardly different from using triggers anyway.
The alternatives are the various SELECT queries that you've already seen.
Alban Hertroys
--
If you can't see
from the
mistakenly assumed MySQL from earlier replies :P
Alban Hertroys
--
If you can't see the forest for the trees,
cut the trees and you'll see there is no forest.
!DSPAM:737,4e139a9a12091547611509!
--
Sent via pgsql-general mailing list (pgsql-general@postgresql.org)
To make changes
as
much shared memory configured in the kernel as the first has?
Alban Hertroys
--
Screwing up is an excellent way to attach something to the ceiling.
!DSPAM:737,4e109dd612097665720452!
--
Sent via pgsql-general mailing list (pgsql-general@postgresql.org)
To make changes to your
that in the client and redo the transaction with a new
ID, but if that's not acceptable (for example because it matters which
transaction got the ID first) then you need to lock records.
Alban Hertroys
--
If you can't see the forest for the trees,
cut the trees and you'll see there is no forest.
!DSPAM
this warrants a documentation patch? It goes at least as far back as
8.2, the oldest online documentation on the site, maybe even as far back as 7.4
(the first version I used) or earlier.
Alban Hertroys
--
If you can't see the forest for the trees,
cut the trees and you'll see there is no forest
want to do that more often
than strictly necessary. In that case you could probably use beginTransaction
at the start of your script and commit at the end.
But that all depends on your requirements, of course.
Alban Hertroys
--
If you can't see the forest for the trees,
cut the trees and you'll
to implement the logic via
trigger?
This is very similar to what was recently discussed in the topic Constraint to
ensure value does NOT exist in another table? in this list.
Alban Hertroys
--
If you can't see the forest for the trees,
cut the trees and you'll see there is no forest.
!DSPAM
though, you violate the UNIQUE constraint on Table3.ColA.
It's probably convenient to write some triggers to auto-generate the records in
Table3, but those triggers are NOT needed for relational integrity - they just
make the task easier.
Alban Hertroys
--
If you can't see the forest
persistent
connections. Having both doesn't make sense to me.
Alban Hertroys
--
Screwing up is an excellent way to attach something to the ceiling.
!DSPAM:737,4dfaf87012091396613445!
--
Sent via pgsql-general mailing list (pgsql-general@postgresql.org)
To make changes to your subscription
, custom function, etc?
Thanks!
Perhaps it's possible to use a unique constraint in a third table to guarantee
those foreign keys can never have the same value. That would probably be more
efficient than executing stored procedure code.
Alban Hertroys
--
Screwing up is an excellent way
(by the process with pid 1871) on that
table that's preventing the database from altering the table. Close that
session and it should continue.
Alban Hertroys
--
Screwing up is an excellent way to attach something to the ceiling.
!DSPAM:737,4dfa4bb912092131128697!
--
Sent via pgsql-general
it?
Alban Hertroys
--
Screwing up is an excellent way to attach something to the ceiling.
!DSPAM:737,4df7066c12091187585653!
--
Sent via pgsql-general mailing list (pgsql-general@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-general
going to happen.
Alban Hertroys
--
Screwing up is an excellent way to attach something to the ceiling.
!DSPAM:737,4df7070412091158319318!
--
Sent via pgsql-general mailing list (pgsql-general@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-general
On 5 Jun 2011, at 17:17, Andre Majorel wrote:
Does anyone know of a document comparing SQLite and PostgreSQL ?
Indirectly, yes: http://en.wikipedia.org/wiki/Apples_and_oranges
Alban Hertroys
--
If you can't see the forest for the trees,
cut the trees and you'll see there is no forest
On 29 May 2011, at 23:55, Stefan Keller wrote:
Hi Alban
On 2011/5/29 Alban Hertroys wrote:
On 29 May 2011, at 19:45, Stefan Keller wrote:
But I'm hesitating to use ANALYZE for two reasons:
1. It's very slow: it repeadly takes 59000 ms on my machine.
ANALYZE on a single table takes 59s
subscription:
http://www.postgresql.org/mailpref/pgsql-general
Alban Hertroys
--
Screwing up is an excellent way to attach something to the ceiling.
!DSPAM:737,4de2b6f311926797845409!
--
Sent via pgsql-general mailing list (pgsql-general@postgresql.org)
To make changes to your subscription
scan the table only once and you also moved your handling of such
errors into the database (which means that if other applications than your
client ever write values to that table, the same rules are applied).
Alban Hertroys
--
Screwing up is an excellent way to attach something to the ceiling
wrong. An overflowing number still is a number, and throwing an error when it
overflows is the correct thing to do. There's something wrong in your queries
and it needs fixing.
Alban Hertroys
--
Screwing up is an excellent way to attach something to the ceiling.
!DSPAM:737,4ddb717d11921570220170
a function is not an operator.
Alban Hertroys
--
If you can't see the forest for the trees,
cut the trees and you'll see there is no forest.
!DSPAM:737,4ddb741511921606159980!
--
Sent via pgsql-general mailing list (pgsql-general@postgresql.org)
To make changes to your subscription:
http
difference too. Perhaps you could
give us a better example, or show us the actual code even?
Alban Hertroys
--
If you can't see the forest for the trees,
cut the trees and you'll see there is no forest.
!DSPAM:737,4ddb79f211928090216264!
--
Sent via pgsql-general mailing list (pgsql
) doesn't work.
Now calling such functions will probably work just the same as the cast in most
cases, but there will be some discrepancies, as follows from reading:
http://www.postgresql.org/docs/9.0/interactive/sql-createcast.html
Alban Hertroys
--
Screwing up is an excellent way to attach
On 22 May 2011, at 24:08, Wei wrote:
Can anyone help?
According to the error message there's a problem with your TEMP directory, as
specified in the %TEMP% environment variable. Perhaps the postgres user isn't
allowed to write there or the disk is full. Something like that.
Alban Hertroys
the difference between row-level triggers and statement-level
triggers, so it depends on which of those you use.
Alban Hertroys
--
Screwing up is an excellent way to attach something to the ceiling.
!DSPAM:737,4dccd14f11921626814358!
--
Sent via pgsql-general mailing list (pgsql-general@postgresql.org
to access.
Alban Hertroys
--
Screwing up is an excellent way to attach something to the ceiling.
!DSPAM:737,4dba5f4212121823650944!
--
Sent via pgsql-general mailing list (pgsql-general@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-general
it was, which would indicate that
dead rows are the cause. In older versions you could as well, but you'll want
to REINDEX after that. That's not a solution though, only a test ;)
Alban Hertroys
--
Screwing up is an excellent way to attach something to the ceiling.
!DSPAM
AS ON INSERT TO foo
DO INSTEAD
INSERT INTO realfoo (foo, realbar, baz) VALUES (NEW.foo,
NEW.bar::numeric, NEW.baz);
CREATE RULE foo_update ...etc.
That way you're calculating and sorting with actual numeric values, but your
application still sees a varchar field.
Alban Hertroys
On 28 Apr 2011, at 17:29, Alban Hertroys wrote:
With 2.5GB of memory (such a strange number) the docs suggest about 250MB.
Correction, 25% of 2.5GB isn't 250MB of course. It would be somewhat over
500MB, although it's really just a rule-of-thumb (no point in calculating exact
numbers). Anyway
didn't provide PG with
enough resources to work with efficiently?
Alban Hertroys
--
Screwing up is an excellent way to attach something to the ceiling.
!DSPAM:737,4db8fc3811671483513299!
--
Sent via pgsql-general mailing list (pgsql-general@postgresql.org)
To make changes to your subscription
import
into a new environment. Might be worth looking into.
Alban Hertroys
--
If you can't see the forest for the trees,
cut the trees and you'll see there is no forest.
!DSPAM:737,4db72c7511671681815569!
--
Sent via pgsql-general mailing list (pgsql-general@postgresql.org)
To make changes
;)
Alban Hertroys
--
If you can't see the forest for the trees,
cut the trees and you'll see there is no forest.
!DSPAM:737,4db5b02411674566889782!
--
Sent via pgsql-general mailing list (pgsql-general@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql
with the EXPLAIN ANALYSE command.
And also the timing result that gets displayed, in which log file does it get
recorded?
None, as you're doing your measurements client-side. EXPLAIN ANALYSE is
server-side.
Alban Hertroys
--
If you can't see the forest for the trees,
cut the trees and you'll see
PK instead. I don't know
enough about your data to make more than a guess though, I just get itchy when
I see such designs ;)
Alban Hertroys
--
If you can't see the forest for the trees,
cut the trees and you'll see there is no forest.
!DSPAM:737,4db0665111731275120228!
--
Sent via pgsql
be) forward compatible to
database versions that don't yet exist when it is released.
*Always* use a dump made with pg_dump from the newer database if you're
upgrading. Especially between major versions of the database.
Alban Hertroys
--
If you can't see the forest for the trees,
cut the trees
it. Otherwise single UPDATE and INSERT
statements outside of transaction blocks would not COMMIT, and they do.
Alban Hertroys
--
If you can't see the forest for the trees,
cut the trees and you'll see there is no forest.
!DSPAM:737,4d983b2f651341263218540!
--
Sent via pgsql-general mailing
to modify that row to
alter the table definition.
Oracle and SQL server don't suffer from this because they do not handle DDL
statements transactionally (I could be mistaken about SQL server, I don't know
it all that well).
Alban Hertroys
--
If you can't see the forest for the trees,
cut
On 3 Apr 2011, at 11:22, Alban Hertroys wrote:
Oracle and SQL server don't suffer from this because they do not handle DDL
statements transactionally (I could be mistaken about SQL server, I don't
know it all that well).
I forgot to mention, if you perform DDL in Oracle all your currently
controller
or motherboard? Maybe the new drive has different requirements than the old one
had (more power, for example)?
Alban Hertroys
--
If you can't see the forest for the trees,
cut the trees and you'll see there is no forest.
!DSPAM:737,4d8a454f651341486416489!
--
Sent via pgsql-general
, optimisation
*** http://www.sqlspot.com *
--
Sent via pgsql-general mailing list (pgsql-general@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-general
Alban Hertroys
--
Screwing up is an excellent way
/current/static/sql-syntax-lexical.html#SQL-SYNTAX-DOLLAR-QUOTING):
INSERT INTO mytypetable VALUES (
5, $${ ('a', 'aa'), ('b', 'bb') }$$ );
Alban Hertroys
--
Screwing up is an excellent way to attach something to the ceiling.
!DSPAM:737,4d848304235883070015353!
--
Sent via pgsql-general
;
# select u.id, u.first_name, sum(m.completed)
from pref_users u, pref_match m
where u.id=m.id and u.id like 'DE%'
group by u.id, u.first_name
having sum(m.completed) 30
order by sum desc limit 3;
Alban Hertroys
--
If you can't see the forest for the trees,
cut the trees and you'll see
be optimised for
different values of parameters anymore. Not what you want.
Alban Hertroys
--
If you can't see the forest for the trees,
cut the trees and you'll see there is no forest.
!DSPAM:737,4d8069c0235881427912932!
--
Sent via pgsql-general mailing list (pgsql-general@postgresql.org
to use Savepoint and rollback to savepoint in function.
I know Postgresql has autocommit. But I want to rollback to a particular
savepoint.
Within functions you can use exceptions with begin/end blocks to get the same
behaviour as savepoints and rollbacks.
Alban Hertroys
--
If you can't see
exclude the PG data directories from your file-system
backups, there isn't much point in backing them up anyway.
Alban Hertroys
--
Screwing up is an excellent way to attach something to the ceiling.
!DSPAM:737,4d7f0b68235882060612259!
--
Sent via pgsql-general mailing list (pgsql-general
On 15 Mar 2011, at 7:46, Alban Hertroys wrote:
On 15 Mar 2011, at 3:06, Rajesh Kumar Mallah wrote:
Dear Friends,
While taking online basebackup we ignore tar exit codes of 1 .
However under certain circumstances tar exits we code '2' which
stands for 'Fatal Errors' . Eg in case
better accuracy.
Whether this is practical to do is another question entirely, I just thought of
this while reading this thread ;)
Alban Hertroys
--
If you can't see the forest for the trees,
cut the trees and you'll see there is no forest.
!DSPAM:737,4d760ff7235881825915661!
--
Sent via
of concurrency.
Alban Hertroys
--
If you can't see the forest for the trees,
cut the trees and you'll see there is no forest.
!DSPAM:737,4d7365c5235885600661482!
--
Sent via pgsql-general mailing list (pgsql-general@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org
On 2 Mar 2011, at 9:35, chris r. wrote:
GB). Note that we ran VACUUM FULL on the tables affected.
Did you also REINDEX them?
Alban Hertroys
--
Screwing up is an excellent way to attach something to the ceiling.
!DSPAM:737,4d6e8542235882633876383!
--
Sent via pgsql-general mailing list
those records.
Alban Hertroys
--
If you can't see the forest for the trees,
cut the trees and you'll see there is no forest.
!DSPAM:737,4d6bf0da235882099214672!
--
Sent via pgsql-general mailing list (pgsql-general@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org
.
On Mon, Feb 28, 2011 at 7:00 PM, Alban Hertroys
dal...@solfertje.student.utwente.nl wrote:
On 28 Feb 2011, at 24:37, David Johnston wrote:
Using pl/pgsql you can:
You don't need pl/pgsql for that. You can return the resultset of the first
insert into a client-side variable (while still
401 - 500 of 1292 matches
Mail list logo
