ith more familiarity with encoding conversion issues
could comment on that? Otherwise I think this is ready to be bumped up
for committer review.
- Josh Williams
--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-hackers
o not include the file
extension, but msvc was still trying to give it "sql_help.h".
Quickpatch attached.
Wondered why my attempts to test and review another patch were suddenly
confounded...
> regards, tom lane
- Jos
The new version probably won't look at all
like the current one, so no need to waste reviewer cycles on it.
I'll work on a revised version; feel free to mark it as such in the mean
time. Thanks,
- Josh Williams
--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
T
on what else finds
its way into the system catalogs later (but then, probably not much more
so than INFORMATION SCHEMA is.) Would that be preferable, over a couple
additional functions?
- Josh Williams
--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-hackers
posed in other ways. Anyone have any input there on how
this could be expanded?
Anyway, as an immediate practical example the patch modifies psql's
describe-verbose on sequences to show the ownership information...
postgres=# \d+ tbl_id_seq
(...)
Owner: public.tbl.id
- Josh Williams
Index:
o request another yet.
On that note, and now that I'm back online and clean of Pennsic dust,
anything else in this CommitFest in need of a last minute Windows
run-through?
- Josh Williams
* I could envision having the ability to write reviews directly into the
commitfest web app, where one
On Tue, 2009-07-28 at 23:38 -0400, Josh Williams wrote:
> Huh, running the patched version on a single thread with 128 clients
> just got it to crash. Actually consistently, three times now. Will try
> the same thing on the development box tomorrow morning to get some
> bett
t was just indicating a limitation of the environment, where
Windows has some kind of inefficiency either in the PG port or just
something inherent in how the OS works. It does make me wonder where
exactly all that CPU time is going, though. OProfile, how I miss thee.
But that's a different di
unching the requested number of worker threads when looking at the
process. Adjusting the worker thread count down to match the number of
cores yielded identical results in the couple of test cases I ran.
Maybe pgbench itself is less of a bottleneck in this environment,
relatively speaking?
- J
red in poly_contain().
Otherwise it seems to do exactly what it promises. I could see the
correct behavior of these operators being important for GIS
applications. +1 for committer review.
- Josh Williams
--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make change
ships.
Perhaps a function to do the reverse of pg_get_serial_sequence()? Or
better yet if no one else is already working on it, a more generic way
to get readable information out of pg_depend?
>
> regards, tom lane
>
- Josh Williams
--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-hackers
the change on the sequence immediately while
pg_depend wouldn't be seen to change until committed. That, and
ROLLBACK wouldn't work at all...
The column info query is getting messy. Could probably clean that up a
bit if anyone thinks it'd b
12 matches
Mail list logo
