On 28 October 2011 13:37, Alban Hertroys wrote:
> On 28 October 2011 09:02, Mohamed Hashim wrote:
Please don't cross-post to mailing lists for multiple projects.
--
If you can't see the forest for the trees,
Cut the trees and you'll see there is no forest.
--
Sent via pgs
On 28 October 2011 09:02, Mohamed Hashim wrote:
> EXPLAIN select * from stk_source ;
> QUERY
> PLAN
> -
> Result (cost=0.00..6575755.39 rows=163132513 width=42)
> -> Appen
On 26 October 2011 10:08, Alexander Farber wrote:
> create table pref_games {
> gid serial,
> rounds integer not null,
> finished timestamp default current_timestamp
> }
> then how do I find the new game id after I've just created it here:
>
> create or
20238_004.htm
Curiously enough the rather fine manual isn't very verbose on this subject. In
the 9.2-devel docs there is even a section named "Calling functions", but it
seems to focus on writing functions instead.
Alban Hertroys
--
The scale of a problem often
table 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 18 October 2011 14:11, salah jubeh 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
> using the \i o
On 18 October 2011 09:57, 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 create the table if it
On 17 October 2011 17:25, Steve Crawford wrote:
> On 10/16/2011 04:39 PM, Scott Marlowe wrote:
>>
>> On Sun, Oct 16, 2011 at 5:24 PM, Tom Lane wrote:
>>>
>>> Scott Marlowe writes:
On Sat, Oct 15, 2011 at 2:20 PM, Thomas Kellerer
wrote:
>
> Total runtime: -2.368 ms<< t
On 17 October 2011 16:24, Merlin Moncure wrote:
> On Mon, Oct 17, 2011 at 8:44 AM, Alban Hertroys wrote:
>> On 17 October 2011 15:20, Merlin Moncure wrote:
>>> A better way to do this is to query information_schema:
>>>
>>> PERFORM 1 FROM information_sch
On 17 October 2011 15:20, Merlin Moncure 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 code -- do
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 wrote:
>> Anyway, I think you get the sequential scans because the UNION requires to
>> sort all the data from both tables to guarantee that t
Check that windows hasn't been restoring a checkpoint with those dll's 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
N.
Do you really need unique results from that view, or are duplicates acceptable
(one from each 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.
--
Sent via pgsql-general mailing list (pgsql-general@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-general
On 13 October 2011 14:20, Ivan Voras 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
> 3.
On 11 October 2011 15:41, Tom Lane wrote:
> Alban Hertroys 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
On 11 October 2011 16:06, Eric Radman 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 means of abstraction
>
amp ) + 10 *
3600) / 300), floor((extract( epoch from '2011-08-22 08:42:30'::timestamp ) +
10 * 3600) / 300);
floor | floor
-+-
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
On 10 October 2011 10:30, AI Rumman 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 will not give m
On 6 October 2011 12:18, Adarsh Sharma 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 link I sent you, you don't
On 6 October 2011 11:04, Adarsh Sharma 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 can't see the forest for
st. It doesn't prevent accidental truncating.
If that's why the errors occur, they're at least a bit misleading. I can't 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
--
Sc
On 3 October 2011 08:33, Alexander Pyhalov 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
> ---
> 89
>
On 30 September 2011 11:20, J.V. 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 well?
They do if
On 29 September 2011 13:12, Radosław Smogura 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 not, you might ha
On 28 September 2011 13:19, salah jubeh 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 column
> values.
On 26 September 2011 17:15, Edson Carlos Ericksson Richter
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 mailing list (pgsql-g
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,
, but you seem to base your
hypothesis on wrong assumptions.
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
n the
regex table is stored. That's some huge overhead, but it will probably
outperform most other options. With the numbers you gave that table 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 t
On 23 September 2011 14:29, 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 th
On 23 September 2011 12:31, Ingmar Brouns 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 they
>
On 23 September 2011 09:45, wrote:
> Alban Hertroys 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?
>
On 23 September 2011 11:47, Andrew Rose 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 records you need to scan at ev
On 21 September 2011 17:59, 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 codes
> against
On 19 September 2011 12:01, Koen Van Impe 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 suspect I should
an the starting ID of your sequence? Or that there isn't another
process 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 t
>
> 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 i
On 16 September 2011 03:31, Adrian Klaver 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 misplaced fields.
>
GW-22 2005-03-09 Depth to Water \N Feet\N
> \N\N \N
>
> (It is a single 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
e error is about the line after the one you showed us. If
there isn't a terminator (\.) 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 colu
it's faster to do a seqential scan. I'll 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 inde
sequential scan turns into
> an index scan, but sadly this can't always be done.
Does it make sense to CLUSTER your data in some sense? That would improve the
data distribution issue and would probably push the threshold for a seqscan up
some.
Cheers,
Alban Hertroys
--
If you can'
70-01-01 being the baseline for their calculations is a bit of a
guess, 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 Hertroy
gin_table,
>c.oid AS referencing_id,
>c.oid::regclass::text AS referencing_table,
Only the 'root'-nodes of the recursive tree are going through that part of the
UNION. Those don't have an origin. It's a matter of choice what to do in that
ns. Each join is kept with its relevant conditions
even, so it's immediately clear which conditions pertain to which joins.
I find in general explicit inner joins improve readability of queries over
implicit joins, especially when the joins get a little more complicated.
Perhaps what you f
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 yo
#x27;t the trigger
> execute 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
into an
"application server", while you put data integrity logic ("don't allow
transactions 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-genera
h idcolor2=old.idvalue was found:
if FOUND then
new.idcolor := a;
endif
return new;
That saves a few unnecessary CPU cycles.
Alban Hertroys
--
The scale of a problem often equals the size of an ego.
!DSPAM:737,4e2a8d6912091302916282!
--
Sent via pgsql
same date? Just joining on date doesn't 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 su
7;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 can't see the forest for the trees,
cut the trees and you'll see
n't have any records in traffic where there's 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
--
S
L) is unique in this table.
The uniqueness of that tuple 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 H
t mentioning it doesn't hurt
anyone, and there could be some caveats in that process. Both databases are
fairly SQL compliant though, it's probably an easier conversion than from the
mistakenly assumed MySQL from earlier replies :P
Alban Hertroys
--
If you can't see the forest f
that by updating the latest row
and the last latest row to reflect 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 SE
ed to import massive datasets, only 20-30K records
>> at a time.
>>
>> Thanks much
>>
>> Jonathan
>>
>>
>>
>
>
> --
> Sent via pgsql-general mailing list (pgsql-general@postgresql.org)
> To make changes to your subscription:
> http://w
le, or
2. Update a foreign key 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
t.
It's possible to catch 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
check: Does the second server have at least 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@p
e not null. MATCH PARTIAL is not yet implemented."
Perhaps 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 f
l, but use a global $db object instead. Creating
DB-connections is relatively expensive, so you don't 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
nt ot do I need 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
Is transaction mode better for PHP scripts with
> persistent connections? I'll try that, thank you
> (rebooting right now... GPRS sucks)
I think the intention was to use a pooler INSTEAD OF php persistent
connections. Having both doesn't make sense to me.
Alban Hertroys
--
Screwing
ble3.ColA (without the "src"
column).
Now, if you add a value to Table1, it requires a value of (ColA, 'A') in
Table3. If you add one to Table2, it requires a value of (ColA, 'B'). If either
of those already exist though, you violate the UNIQUE constraint on Tab
r any fix available?
You have some uncommitted transaction (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.
HECK constraint, trigger, 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
tter, because that _is_ 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.
tted a crime.
So what exactly is the encryption supposed to solve? Do you really need 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
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
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
to date. Since ANALYZE only tests a sampling of
>> records it does pretty much what you want, something that it's not so easy
>> to do in SQL.
>>
>> --
>> Craig Ringer
>>
>
> --
> Sent via pgsql-general mailing list (pgsql-general@postgresql.org)
> T
t;
> ERROR: relation "user_news_tmp2" does not exist
> CONTEXT: compilation of PL/pgSQL function "create_user_report2" near line 22
Well, according to the code you provided your table is named "a", and not
"user_news_tmp2". There's obviously s
d that, but in short: Because 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 chan
#x27;device' and parameter in
>> ('RVT_2P_NOM_1UX5_N_VTSAT');
> I wonder whether the behaviour can
> be optimized, such that the individual value can be set to 'nan'
> instead of causing a fail for the entire query.
That would be a really bad idea. It is a nu
can
use the NEW.* and OLD.* variables to alter the row before it gets written. That
way you 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
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.
A
transformation function that's used by the cast. It
just happens to be called the same as the type in some cases, which is why
boolean(value) 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,
e.
That's just 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 mai
rict
access to the schema the user isn't supposed 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
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
num
foo AS SELECT foo, realbar::text as bar, baz FROM realbar;
CREATE RULE foo_insert 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 actu
CUUM FULL (before you increase shared_buffers) and
see whether your performance is back where 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
al runtime: 8150.949 ms"
>
> It seems that the GIN index was not used.
But it _is_ being used. It takes almost 1ms per row it finds though, I wonder
why that is. Maybe you're using slow hardware or you didn't provide PG with
enough resources to work with efficiently?
Alban
their contents
in a consistently formatted file (often XML) that it can subsequently 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!
t's a frequently recurring issue on this list, there's bound to be some
pointers in the archives ;)
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
s? If not, you may well be better
off dropping them. That way (code, term) could be your 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 th
amiliar 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 tre
x27;t (and can't 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
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 p
least
one row at the start of your session, preventing Postgres 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
implicitly COMMITs 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!
--
S
al
hardware damage to, for example, your raid controller, cables, disk 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 th
>>
>> and course_cross_section IS NULL
>>
>> )
>>
>> and user_id not in (select user_id from instr_as_stutemp)
>>
>
>
> --
> Frédéric BROUARD - expert SGBDR et SQL - MVP SQL Server - 06 11 86 40 66
> Le site sur le langage S
ES (
5, '{ (''a'', ''aa''), (''b'', ''bb'') }' );
Or use dollar-quoting
(http://www.postgresql.org/docs/current/static/sql-syntax-lexical.html#SQL-SYNTAX-DOLLAR-QUOTING):
INSERT INTO mytypetable VALUES (
5, $${ ('a&
> Please advice how 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 H
query plan is
already set in stone - it will be a generic plan that can't 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,4d8
first_name
> order by sum desc limit 3;
# 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 s
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' whi
were dropped during the backup. But that is
> quite normal also.
You should probably 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.
ime and the
distribution of users at that date.
Combining both will give you 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 yo
401 - 500 of 1306 matches
Mail list logo
