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 dat
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-manageme
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 evaluated for each row that
qualifies."
p. 556: ::=
ARRAY_AGG
[ ORDER BY ]
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
thei
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 trans
"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
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 Guillau
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
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_sc
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 i
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 contents.
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 somethi
* 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 con
[ 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
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 pro
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 ma
> 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:\pgdev>dumpbin
Microsoft (R) COFF/PE Dumper Version 8.00.50727.762
Copyright (C) Microsof
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 src\tools\m
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.
>
>
"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.
regards, tom lane
-
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 c
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 cont
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
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
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.
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 tabl
"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
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 archi
"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)---
TI
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
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 ap
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:
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.
No
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
34 matches
Mail list logo
