On 27/01/2008, [EMAIL PROTECTED] [EMAIL PROTECTED] wrote:
On Sat, Jan 26, 2008 at 07:32:35PM +0100, Ivan Voras wrote:
Andrew Dunstan wrote:
[...]
Or you could use an hstore (see contrib).
Doesn't seem applicable.
Have a closer look: it might :-)
I found these documents on hstore:
It occurred to me the other day that synchronized scans could play havoc with
clustered tables. When you dump and reload a table even if it was recently
clustered if any other sequential scans are happening in the system at the
time you dump it the dump could shuffle the records out of order.
Ivan Voras wrote:
On 27/01/2008, [EMAIL PROTECTED] [EMAIL PROTECTED] wrote:
On Sat, Jan 26, 2008 at 07:32:35PM +0100, Ivan Voras wrote:
Andrew Dunstan wrote:
[...]
Or you could use an hstore (see contrib).
Doesn't seem applicable.
Have a closer look:
On Jan 27, 2008 6:45 PM, Tom Lane [EMAIL PROTECTED] wrote:
Yeah, Rae Steining was complaining to me about that off-list a few weeks
ago. The whole syncscan behavior risks breaking many apps that always
worked before, even if they were disregarding the letter of the SQL spec.
Maybe a GUC
Guillaume Smet [EMAIL PROTECTED] writes:
Would it need a restart and be a global GUC variable or
could it be set temporarily per session?
It could be PGC_USERSET, afaics.
regards, tom lane
---(end of broadcast)---
TIP 6:
Gregory Stark [EMAIL PROTECTED] writes:
Perhaps we should have some form of escape hatch for pg_dump to request real
physical order when dumping clustered tables.
Yeah, Rae Steining was complaining to me about that off-list a few weeks
ago. The whole syncscan behavior risks breaking many apps
On Jan 27, 2008 7:14 PM, Tom Lane [EMAIL PROTECTED] wrote:
It could be PGC_USERSET, afaics.
If so, it seems like a good idea even if it's just for debugging purposes.
--
Guillaume
---(end of broadcast)---
TIP 4: Have you searched our list
Guillaume Smet [EMAIL PROTECTED] writes:
Maybe a GUC variable to enable/disable syncscan?
If so, it seems like a good idea even if it's just for debugging purposes.
Do we have nominations for a name? The first idea that comes to mind
is synchronized_scanning (defaulting to ON).
Also, does
On Jan 27, 2008 7:37 PM, Tom Lane [EMAIL PROTECTED] wrote:
Also, does anyone object to making pg_dump just disable it
unconditionally? Greg's original gripe only mentioned the case of
clustered tables, but it'd be kind of a pain to make pg_dump turn it
on and off again for different tables.
Hi,
I get the following error when: build.bat DEBUG
somehow dumpbin is not called.
analyze.c
Compiling resources...
Generate DEF file
Generating POSTGRES.DEF from directory Debug\postgres
...Could not call dumpbin at src\tools\msvc\gendef.pl line
22.
2008/1/28, Tom Lane [EMAIL PROTECTED]:
Do we have nominations for a name? The first idea that comes to mind
is synchronized_scanning (defaulting to ON).
synchronized_sequential_scans is a bit long, but contains the
keyword sequential scans, which will ring a bell with many, more so
than
Hello,
is it means some PostgreSQL specific?
regards
Pavel Stehule
---(end of broadcast)---
TIP 5: don't forget to increase your free space map settings
On Jan 27, 2008 9:07 PM, Markus Bertheau [EMAIL PROTECTED] wrote:
2008/1/28, Tom Lane [EMAIL PROTECTED]:
Do we have nominations for a name? The first idea that comes to mind
is synchronized_scanning (defaulting to ON).
synchronized_sequential_scans is a bit long, but contains the
On Sun, Jan 27, 2008 at 09:10:31PM +0100, Pavel Stehule wrote:
Hello,
is it means some PostgreSQL specific?
Not really. The main thing is that many symbols in gram.y eventually
get turned into a #define and if the symbol is a normal looking word
that may be used in another context it's
On 27/01/2008, Tom Lane [EMAIL PROTECTED] wrote:
Pavel Stehule [EMAIL PROTECTED] writes:
is it means some PostgreSQL specific?
I think the original idea was P-for-Parser. It's just there for tokens
whose macros would otherwise be likely to collide with other symbols.
Do you have the dumpbin command available in the path?
//Magnus
:) yes. This is why I do not understand why the command does not run
correctly!
=
I:\pgdevdumpbin
Microsoft (R) COFF/PE Dumper Version 8.00.50727.762
Copyright (C) Microsoft
Gevik Babakhani wrote:
Hi,
I get the following error when: build.bat DEBUG
somehow dumpbin is not called.
analyze.c
Compiling resources...
Generate DEF file
Generating POSTGRES.DEF from directory Debug\postgres
...Could not call dumpbin at
Whilst trying to reproduce bug #3902 I noticed that the code doesn't
work with an abbreviated host name:
$ psql -l -h rh2.sss.pgh.pa.us
List of databases
... everything's fine ...
$ psql -l -h rh2
psql: GSSAPI continuation error: Unspecified GSS failure. Minor code
If you do a manual kill -9 (for testing purposes) on its connected
server process, psql normally recovers nicely:
regression=# select 1;
?column?
--
1
(1 row)
-- issue kill here in another window
regression=# select 1;
server closed the connection unexpectedly
This
[ redirecting thread to -hackers ]
Neil Conway [EMAIL PROTECTED] writes:
On Sun, 2008-01-27 at 21:54 +, Gregory Stark wrote:
I liked the synchronized_sequential_scans idea myself.
I think that's a bit too long. How about synchronized_scans, or
synchronized_seqscans?
We have
* Tom Lane ([EMAIL PROTECTED]) wrote:
Whilst trying to reproduce bug #3902 I noticed that the code doesn't
work with an abbreviated host name:
$ psql -l -h rh2.sss.pgh.pa.us
List of databases
... everything's fine ...
$ psql -l -h rh2
psql: GSSAPI
Stephen Frost [EMAIL PROTECTED] writes:
* Tom Lane ([EMAIL PROTECTED]) wrote:
Whilst trying to reproduce bug #3902 I noticed that the code doesn't
work with an abbreviated host name:
Testing w/ 8.3RC2, everything seems to be working fine here:
Okay, that probably means there's something
Greetings,
In doing some test on 8.3RC2, I was dismayed to discover that the
pl/pgsql plan invalidation logic added doesn't consider changing the
search_path to invalidate a plan.
Our case is where we have a number of schemas with identical table
structures but differing table
Stephen Frost [EMAIL PROTECTED] writes:
In doing some test on 8.3RC2, I was dismayed to discover that the
pl/pgsql plan invalidation logic added doesn't consider changing the
search_path to invalidate a plan.
We never considered it so before, either. The plancache code goes out
of its
On Jan 27, 2008, at 21:04 , Tom Lane wrote:
[ redirecting thread to -hackers ]
Neil Conway [EMAIL PROTECTED] writes:
On Sun, 2008-01-27 at 21:54 +, Gregory Stark wrote:
I liked the synchronized_sequential_scans idea myself.
I think that's a bit too long. How about synchronized_scans,
On Jan 27, 2008 10:45 PM, Tom Lane [EMAIL PROTECTED] wrote:
Stephen Frost [EMAIL PROTECTED] writes:
In doing some test on 8.3RC2, I was dismayed to discover that the
pl/pgsql plan invalidation logic added doesn't consider changing the
search_path to invalidate a plan.
We never
Merlin Moncure [EMAIL PROTECTED] writes:
On Jan 27, 2008 10:45 PM, Tom Lane [EMAIL PROTECTED] wrote:
If we were to change this, we'd probably have to think in terms of
making the active search_path be part of the lookup key for cached plans.
For the record, IMO it would on balance be better
Michael Glaesemann [EMAIL PROTECTED] writes:
Neil Conway [EMAIL PROTECTED] writes:
I think that's a bit too long. How about synchronized_scans, or
synchronized_seqscans?
Would it make sense to match the plural as well?
Actually, the best suggestion I've seen so far is Guillaume's
Does not virtual transaction IDs in 8.3 help us to shorten vacuum threshold?
I think we can remove recently dead tuples even if non-serializable read-only
transactions are still alive, because those transactions will not see older
versions of tuples.
Another strange thing is that if an open
ITAGAKI Takahiro [EMAIL PROTECTED] writes:
I think we can remove recently dead tuples even if non-serializable read-only
transactions are still alive, because those transactions will not see older
versions of tuples.
Surely this'd require having those transactions display exactly what
their
I recently noticed that SQL:200n[1] defines a new aggregate function,
array_agg(). The relevant portions of the spec are:
p. 66: If ARRAY_AGG is specified, then an array value with one element
formed from the value expression evaluated for each row that
qualifies.
p. 556: array aggregate
Tom Lane [EMAIL PROTECTED] wrote:
Surely this'd require having those transactions display exactly what
their current oldest-xmin is. We've talked about that before, and it
seems a good idea, but it requires a bit more infrastructure than is
there now --- we'd need some snapshot-management
Dear All,I am currently using PostgreSQL database version 8.0.13. My problem relates to a slow result when a query using a defined view joins to another table for a result.Background: I have 7 tables of invoice transactions. The tables are slightly different in that they record different data
33 matches
Mail list logo
